Internet Standards/CD1.mdf/INET/IETF/WGCHART.TXT

Text File | 1994-10-04 | 154.2 KB | 4,129 lines

Access/Synchronization of the Internet Directories (asid)
---------------------------------------------------------

 Charter

 Current status: active working group

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

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Area Advisor
     Erik Huizer  <[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 where possible towards a hybrid system that ties together
  various forms of Directory Service.  Clearly, protocol-level
  integration is only part of the solution.  But to keep this group
  tightly focused, harmonizing directory information and service models
  will be tackled by other working groups.


 Internet-Drafts:

  No Current Internet-Drafts.


Electronic Data Interchange (edi)
---------------------------------

 Charter

 Current status: active working group

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

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Area Advisor
     John Klensin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       sub ietf-edi <yourname>
     Archive:           ftp.sterling.com:edi/lists

Description of Working Group:

Electronic Data Interchange (EDI) is a set of protocols for conducting
highly structured inter-organization exchanges, such as for making
purchases.  The working group will produce specifications for the use
of EDI standards over the Internet, with an initial focus on the
transport of EDI via Internet e-mail.  The EDI community is large,
diverse and well-established.  This working group effort is explicitly
NOT intending to specify or modify any of the details of EDI protocols
themselves.  Instead, it will focus on the requirements for proper
carriage of EDI over the Internet, attending only to issues of
encapsulation, addressing, security and the like.

Initial efforts by the working group will focus on two deliverables:
specification for the carriage of various EDI content via MIME-based
e-mail, and a discussion document, considering issues in the use of
EDI over the Internet.  The usage document will cover such issues as
addressing and security.


 Internet-Drafts:

  No Current Internet-Drafts.


Internet Message Access Protocol (imap)
---------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Terry Gray <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.cac.washington.edu:~/imap/imap_archive

Description of Working Group:

   The Interactive Mail Access Protocol (IMAP) Working Group
   is chartered to refine and extend the current IMAP2 protocol as a
   candidate standard for a client-server Internet e-mail protocol to
   manipulate remote mailboxes as if they were local.  An explicit
   objective is to retain compatibility with the growing installed base
   of IMAP2-compliant software.  It is expected that the resulting
   specification will replace both RFC 1176 and the more recent (as yet
   unplublished) IMAP2bis extensions document.

   The IMAP Working Group will also investigate how to provide for
   ``disconnected operation'' capabilities similar to the DMSP protocol
   (RFC 1056, with Informational status) with a goal of making it
   possible for IMAP to replace DMSP.

   An e-mail access protocol provides a uniform, operating
   system-independent way of manipulating message data (e-mail or
   bulletin board) on a remote message store (repository).  Mail user
   agents implementing such a protocol can provide individuals with a
   consistent view of the message store, regardless of what type of
   computer they are using, and regardless of where they are connected
   in the network.  Multiple concurrent sessions accessing a single
   remote mailbox, and single sessions accessing multiple remote
   mailboxes, are both possible with this approach.

   This differs from POP3 (RFC 1225) in that POP is a store-and-forward
   transport protocol that allows an MUA to retrieve pending mail from
   a mail drop (where it is then usually deleted automatically),
   whereas IMAP is focused on remote mailbox manipulation rather than
   transport. IMAP differs from various vendor-specific remote access
   approaches in that IMAP is an open protocol designed to scale well
   and accommodate diverse types of client operating systems.

   Security-related tasks include how to incorporate secure
   authentication mechanisms when establishing a session, and possible
   interactions with Privacy Enhanced Mail.

   It is expected that most of the work of this group will be conducted
   via e-mail.  A goal is to integrate and update RFC 1176 and the
   existing IMAP2bis draft, then submit the result as an Internet-Draft
   well before the November 1993 IETF meeting, which would then focus on
   detailed review of the text in preparation for submission as a
   Proposed Standard before the end of 1993.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 94 Aug 94  <draft-ietf-imap-imap4-05.txt>
                INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4

 Jun 94 Jun 94  <draft-ietf-imap-auth-01.txt>
                IMAP4 Authentication mechanisms

 Jun 94 New     <draft-ietf-imap-compat-00.txt>
                IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS

 Jun 94 New     <draft-ietf-imap-disc-00.txt>
                SYNCHRONIZATION OPERATIONS FOR DISCONNECTED IMAP4 CLIENTS

 Aug 94 New     <draft-ietf-imap-model-00.txt>
                DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4


Internet White Pages Requirements (whip)
----------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Tony Genovese <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Area Advisor
     Erik Huizer  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.es.net:/pub/ietf/wps

Description of Working Group:


  At the Seattle IETF in March 1994, a BOF was held on the establishment
  of a Simple Internet White Pages Service (SIWPS).  A basic model was
  proposed, and further work was defined.  One of the requested work items
  was a definition of the basic requirements for such a service.  This
  working group is chartered to produce a single Informational RFC
  capturing these basic requirements.  It will do so without prejudice to
  existing solutions or implementations.

  The requirements document should only contain the basic requirements
  for a SIWPS.  The list is not meant to be exhaustive, but rather should
  provide a set of minimum requirements to guide the overall structure of
  white pages service effort; these requirements can be used by related
  IETF working groups to start to define the Internet white pages service.

  The working group is meant to be short-lived and to produce only the
  one document.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 94 New     <draft-ietf-whip-iwps-requirements-00.txt>
                A Specification for the Simple Internet White Pages Service.


MHS-DS (mhsds)
--------------

 Charter

 Current status: active working group

 Chair(s):
     Kevin Jordan <[e-mail]>
     Harald Alvestrand <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           mercury.udev.cdc.com:~/pub/archives/mhs-ds-archive

Description of Working Group:

The MHS-DS Working Group works on issues relating to Message Handling
Services use of Directory Services.  The message handling services are
primarily X.400, but issues relating to RFC 822 use of Directory and
Directory support for RFC 822 and X.400 interworking are in the scope of
the group.  Directory and Directory Services refer to the services
based upon the CCITT X.500 recommendations and additional ISO
standards, stable implementation agreements, and RFCs, as specified by
the OSI-DS Working Group.  The major aims of the MHS-DS Working Group
are:

1. Define a set of specifications to enable effective, large-scale
deployment of X.400.

2. Study issues associated with supporting X.400 communities which lack
access to X.500 Directory, and define requirements for tools which: (a)
extract information from the X.500 Directory for use by non-X.500
applications, and (b) upload information into the X.500 Directory.

3. Coordinate a pilot project which deploys MHS information into the
X.500 Directory and uses it to facilitate mail routing and address
mapping.  The results of this pilot will be documented, and experience
gained from the project will be fed back into the Internet
specifications created by the working group.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 92 Mar 94  <draft-ietf-mhsds-mhsprofile-04.txt, .ps>
                A simple profile for MHS use of Directory

 Apr 92 Sep 94  <draft-ietf-mhsds-subtrees-06.txt, .ps>
                Representing Tables and Subtrees in the X.500 Directory

 Apr 92 Sep 94  <draft-ietf-mhsds-infotree-06.txt, .ps>
                Representing the O/R Address hierarchy in the X.500 Directory
                Information Tree

 Apr 92 Sep 94  <draft-ietf-mhsds-supmapping-06.txt, .ps>
                Use of the X.500 Directory to support mapping between X.400 and
                RFC 822 Addresses

 Apr 92 Mar 94  <draft-ietf-mhsds-mhsuse-03.txt, .ps>
                MHS use of the Directory to support distribution lists

 Apr 92 Jul 94  <draft-ietf-mhsds-routdirectory-05.txt, .ps>
                MHS use of Directory to support MHS Routing

 Jun 93 Aug 94  <draft-ietf-mhsds-long-bud-intro-02.txt>
                Introducing Project Long Bud:  Internet Pilot Project for the
                Deployment of X.500 Directory Information in Support of X.400
                Routing


Mail Extensions (mailext)
-------------------------

 Charter

 Current status: active working group

 Chair(s):
     C. Allan Cargille <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Area Advisor
     John Klensin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe mailext Your Full Name
     Archive:

Description of Working Group:


   The Mail Extensions Working Group will review, refine as
   needed, and then make a recommendation on standardization of several
   recent proposals for standards-track compatible extensions to SMTP
   (via the Service Extensions mechanism), MIME (via new Content
   Subtypes), and MIME-MHS (via MIME Content Subtypes and usage rules).

   It will also act as the review body for several documents that
   clarify and provide applicability statements about the use of
   Internet mail: that work will ultimately lead to an update for the
   mail-related section of RFC 1123.  Part of that effort involves
   RARE WG-MSG documents that address the Internet's installed
   electronic mail infrastructure.  Since such documents should not
   be processed in RARE alone, this working group will act as the
   IETF focus for reviewing them.

   Initial drafts of all of the documents that the working group is
   expected to review have already been, or will soon be, published.
   The working group will be starting with documents that have been
   prepared as individual (or spontaneous design team) contributions.
   It is not expected to initiate new work. On the other hand, it is
   expected to make explicit "not ready for standardization" or
   "inappropriate for standardization" recommendations if that is
   appropriate.

   The working group will be initialized with the following Internet-
    Drafts or their successors, listed alphabetically.  A major purpose
    of its first meeting is to prune or add to this list.

      draft-freed-ftbp-00.txt

      draft-freed-smtp-pipeline-00.txt

      draft-houttuin-mailservers-02.txt

      draft-rare-msg-a-bombs-00.txt

      draft-rare-msg-c-bombs-00.txt

      draft-vaudreuil-smtp-binary-04.txt

      draft-vaudreuil-smtp-stream-00.txt

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 93 New     <draft-ietf-mailext-lang-char-00.txt>
                Characters and character sets for various languages

 Oct 93 Aug 94  <draft-ietf-mailext-smtp-binary-05.txt>
                SMTP Service Extensions for Transmission of Large and Binary
                MIME Messages

 Dec 93 New     <draft-ietf-mailext-lang-tag-00.txt>
                Tags for the identification of languages

 Jul 94 Sep 94  <draft-ietf-mailext-smtp-521-02.txt>
                SMTP 521 reply code

 Aug 94 New     <draft-ietf-mailext-checkp-00.txt>
                SMTP Service Extension for Checkpoint/Restart

 Aug 94 New     <draft-ietf-mailext-pipeline-00.txt>
                SMTP Service Extension for Command Pipelining


Notifications and Acknowledgements Requirements (notary)
--------------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Harald Alvestrand <[e-mail]>
     Ned Freed <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

 Area Advisor
     John Klensin  <[e-mail]>

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

Description of Working Group:


The purpose of the NOTARY Working Group is to give the Internet e-mail
user better tools to build a system where the sender of a message can
find out what happened to it.

Work items for this group:

- Specify a reporting format that can be used for delivery,
non-delivery and receipt reports. The format should conform to MIME,
and be at least as informative as current examples of non-standardized
non-delivery notifications. This format should be usable as-is in
current e-mail products to replace the current, non-standardized and
sometimes quite cryptic textual non-delivery reports.  The drafts by
Keith Moore and Greg Vaudreuil are taken as a working basis.  (See
the document list below for details.)

- Specify a way for the sender to request that positive delivery
reports be generated for a message sent via SMTP. The draft by
Keith Moore is taken as a working basis.

- Generate an Informational document that gives advice on how to handle
delivery notifications (positive and negative) and requests for them at
boundaries to other mail systems, such as X.400 and PC LANs.

Relationship to X.400 and X.400 gateways:

While the intent of this work includes specification of an
acknowledgement system that can be translated to work across the
821/822/MIME to X.400 boundary, the effort will focus on design from
the former standpoint.  That will be followed by changes to the
successor of RFC 1327 to match these features, but those changes will be
made as part of the RFC 1327 revision process, not by this working group.
Of course, if any features specified by this working group turn out to be
impossible to accomodate in the RFC 1327 revision, that would be cause for
reviewing both sets of specifications.

Additional items not on the agenda of this working group:

- Specification of a way in which the sender can request that a receipt
notification (``the recipient has read this message'') be sent upon
receipt of the message. The document should identify the controversial
aspects of such a function, and should attempt to specify the function
in a way that minimizes surprise at both the sending and receiving end,
even in the face of varying local policies.

However, the group will, as part of its work, make a recommendation to
the IESG where and how such work should be tackled.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 93 Mar 94  <draft-ietf-notary-smtp-drpt-01.txt>
                SMTP Service Extension for Delivery Status Notifications

 Sep 93 Jul 94  <draft-ietf-notary-mime-delivery-02.txt>
                An Extensible Message Format for Delivery Status Notifications

 Aug 94 New     <draft-ietf-notary-mime-report-00.txt>
                Multipart/Report


OSI Directory Services (osids)
------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Steve Kille <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

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

Description of Working Group:

The OSI-DS group works on issues relating to building an OSI Directory
Service using X.500 and its deployment on the Internet.  Whilst this
group is not directly concerned with piloting, the focus is practical,
and technical work needed as a pre-requisite to deployment of an open
Directory will be considered.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 Jul 94  <draft-ietf-osids-cldap-01.txt>
                Connection-less Lightweight Directory Access Protocol


TELNET (telnet)
---------------

 Charter

 Current status: active working group

 Chair(s):
     Steve Alexander <[e-mail]>

 Applications Area Director(s):
     John Klensin  <[e-mail]>
     Erik Huizer  <[e-mail]>

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

Description of Working Group:

The TELNET Working Group will examine RFC 854, ``Telnet Protocol
Specification,'' in light of the last six years of technical
advancements, and will determine if it is still accurate with how the
TELNET protocol is being used today.  This group will also look at all
the TELNET options, and decide which are still germane to current-day
implementations of the TELNET protocol.


(1) Re-issue RFC 854 to reflect current knowledge and usage of the
    TELNET protocol.

(2) Create RFCs for new TELNET options to clarify or fill in any
    voids in the current option set.  Specifically: environment
     variable passing, authentication, encryption, and compression.

(3) Act as a clearing-house for all proposed RFCs that deal with the
    TELNET protocol.



 Internet-Drafts:

  No Current Internet-Drafts.


Address Lifetime Expectations (ale)
-----------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Frank Solensky <[e-mail]>
     Tony Li <[e-mail]>

 IP: Next Generation Area Director(s):
     Scott Bradner  <[e-mail]>
     Allison Mankin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           research.ftp.com:pub/ale/

Description of Working Group:

The primary purpose of the Address Lifetime Expectations Working Group
is to develop an estimate for the remaining lifetime of the IPv4
address space based on currently known and available technologies. The
members of the working group will consider whether more stringent
address allocation and utilization policies might provide additional
time and, if so, recommend such policies. The working group will also
investigate whether it is worthwhile to mount a serious effort to
reclaim addresses and/or to renumber significant portions of the
Internet.  It will also weigh the benefit of other potential options
against their expected cost and notify the responsible working groups
or area directors of those  proposals the ALE group considers worthy of
further attention.

The working group will have several ongoing activities which will
result in reports to the IETF community and the IPng Area Directors.
One ongoing activity is to produce monthly predictions of the address
space exhaustion timeframe, assessing the accuracy of these predictions
and the data on which they are based.  The group will also project the
impact of various policy compliance data and possible policy
recommendations.

Another ongoing activity is to monitor the perceived utilization of
address space and identify sources of poor utilization, set address
utilization goals and to itemize possible policies to improve
utilization.

The group will also monitor the number of routes present in the
Internet backbones, and identify sources of poor aggregation within the
network, (in conjunction with the BGP Deployment Working Group), and make
necessary recommendations to insure continued operations.


 Internet-Drafts:

  No Current Internet-Drafts.


Simple Internet Protocol Plus (sipp)
------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Robert Hinden <[e-mail]>
     Steve Deering <[e-mail]>
     Paul Francis <[e-mail]>

 IP: Next Generation Area Director(s):
     Scott Bradner  <[e-mail]>
     Allison Mankin  <[e-mail]>

 Area Advisor
     Allison Mankin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           parcftp.xerox.com: pub/sipp

Description of Working Group:

Simple Internet Protocol Plus (SIPP) is one of the candidates being
considered in the Internet Engineering Task Force (IETF) for the next
version of the Internet Protocol (IP).  The current version of IP is
usually referred to as IPv4.  The purpose of the working group is to
finalize the SIPP and IPAE specifications, foster the early development
and experimentation of this protocol, and to work toward having SIPP
selected as the IETF's IPng.

SIPP is a new version of IP which is designed to be an evolutionary step
from IPv4.  It is a natural increment to IPv4.  It can be installed as a
normal software upgrade in internet devices and is interoperable with the
current IPv4.  Its deployment strategy is designed to not have any
``flag'' days.  SIPP is designed to run well on high performance networks
(e.g., ATM) and at the same time is still efficient for low bandwidth
networks (e.g., wireless).  In addition, it provides a platform for new
internet functionality that will be required in the near future.


Background:

The SIPP Working Group represents the evolution and merger of three
different IETF working groups focused on developing an IPng.  The first
was called IP Address Encapsulation (IPAE) and was chaired by Dave
Crocker and Robert Hinden.  It proposed extensions to IPv4 which would
carry larger addresses. Much of its work was focused on developing
transition mechanisms.  Somewhat later Steve Deering proposed a new
protocol evolved from IPv4 called the Simple Internet Protocol (SIP).  A
working group was formed to work on this proposal which was chaired by
Steve Deering and Christian Huitema.  SIP had 64-bit addresses, a
simplified header, and options in separate extension headers.  After
lengthy interaction between the two working groups, and the realization
that IPAE and SIP had a number of common elements and the transition
mechanisms developed for IPAE would apply to SIP, the groups decided to
merge and concentrate their efforts.  The chairs of the new SIP Working
Group were Steve Deering and Robert Hinden.  In parallel to SIP, Paul
Francis (formerly Paul Tsuchiya) had founded a working group to develop
the ``P'' Internet Protocol (PIP).  PIP was a new Internet Protocol based
on a new architecture.  The motivation behind PIP was that the
opportunity for introducing a new Internet Protocol does not come very
often and given that opportunity important new features should be
introduced.  PIP supported variable length addressing in 16-bit units,
separation of addresses from identifiers, support for provider selection,
mobility, and efficient forwarding.  It included a transition scheme
similar to IPAE.  After considerable discussion among the leaders of the
PIP and SIP Working Groups, they came to realize that the advanced
features in PIP could be accomplished in SIP without changing the base
SIP protocol, as well as keeping the IPAE transition mechanisms.  In
essence, it was possible to keep the best features of each protocol.
Based on this, the groups decided to merge their efforts.  The new
protocol was called Simple Internet Protocol Plus (SIPP).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 93 Apr 94  <draft-ietf-sipp-bsd-api-02.txt>
                SIPP Program Interfaces for BSD Systems

 Oct 93 Mar 94  <draft-ietf-sipp-dns-01.txt>
                DNS Extensions to support Simple Internet Protocol Plus (SIPP)

 Nov 93 Mar 94  <draft-ietf-sipp-ipae-transition-01.txt>
                IPAE: The SIPP Interoperability and Transition Mechanism

 Jan 94 New     <draft-ietf-sip-unicast-addr-00.txt>
                Simple Internet Protocol Plus (SIPP):  Unicast Hierarchical
                Address Assignment

 Jan 94 Jul 94  <draft-ietf-sipp-routing-addr-02.txt>
                Simple Internet Protocol Plus (SIPP): Addressing Architecture

 Jan 94 Sep 94  <draft-ietf-sipp-sa-03.txt>
                IPv6 Security Architecture

 Jan 94 Aug 94  <draft-ietf-sipp-ap-04.txt>
                IPv6 Authentication Header

 Jan 94 Apr 94  <draft-ietf-sipp-esp-02.txt>
                SIPP Encapsulating Security Payload (ESP)

 Feb 94 Mar 94  <draft-ietf-sipp-dhcpopt-01.txt>
                Simple Internet Protocol Plus (SIPP): DHCP Options and BOOTP
                Vendor Extensions

 Feb 94 New     <draft-ietf-sip-ospf-00.txt>
                OSPF for SIPP

 Feb 94 Jul 94  <draft-ietf-sipp-spec-01.txt>
                Simple Internet Protocol Plus (SIPP) Specification (128-bit
                address version)

 Mar 94 New     <draft-ietf-sipp-icmp-igmp-00.txt>
                ICMP and IGMP for the Simple Internet Protocol Plus (SIPP)

 Mar 94 New     <draft-ietf-sipp-auto-addr-00.txt>
                Simple Internet Protocol Plus (SIPP): Automatic Host Address
                Assignment

 Mar 94 New     <draft-ietf-sipp-whitepaper-00.txt>
                Simple Internet Protocol Plus White Paper

 Jul 94 New     <draft-ietf-sipp-sst-overview-00.txt>
                Simple SIPP Transition (SST) Overview


Common Architecture for Next Generation IP (catnip)
---------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Vladimir Sukonnik <[e-mail]>

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           world.std.com:~/pub/catnip/*

Description of Working Group:

CATNIP is a new version of the IP protocol, converged with a
compressed form of CLNP, and a form of Novell IPX that permits
general interoperation.  The objective is to provide common ground
between the Internet, OSI, and the Novell protocols, as well as to
advance the Internet technology to the scale and performance of the
next generation of internetwork technology. CATNIP has been assigned
the IP version number 7. The CATNIP proposal has evolved from the
TP/IX protocol (RFC 1475) and the TUBA proposal (RFC 1347).

The working group is chartered to review the CATNIP protocol,
evaluate issues arising during product development and deployment
planning, and to document problems and explanations for any parts of
the coexistance with IPv4 not covered directly in the CATNIP-IPv4
interoperation design.

CATNIP includes definitions covering the same ground as the TUBA
project, and within the charter of the TUBA Working Group. This will
be handled by coordination with the TUBA Working Group. The intent is
to arrive at complete alignment between the TUBA work and the CLNP
component in CATNIP.

The group will also continue to be the forum for development of the RAP
protocol and the TCP extensions while in experimental status; this
work will need to be moved to the Transport and Routing Area(s) if it
is to be advanced; this work is outside the charter of the IPng Area.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 93 Mar 94  <draft-ietf-catnip-base-03.txt>
                Common Architecture for Next-generation Internet Protocol

 Mar 94 New     <draft-ietf-catnip-common-arch-00.txt>
                CATNIP: Common Architecture for the Internet


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

 Charter

 Current status: active working group

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

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.merit.edu:/internet/documents/ietf/dns

Description of Working Group:

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

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

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

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

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 94 New     <draft-ietf-dnsind-dynDNS-arch-00.txt>
                Dynamic Updates in the Domain Name System (DNS):  Architecture
                and Mechanism

 Jul 94 New     <draft-ietf-dnsind-dynDNS-impl-00.txt>
                Implementation of Domain Name System (DNS) Dynamic Updates


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

 Charter

 Current status: active working group

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

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           sol.bucknell.edu:~/dhcwg

Description of Working Group:

The purpose of this working group is to investigate network
configuration and reconfiguration management, and determine those
configuration functions that can be automated, such as Internet
address assignment, gateway discovery and resource location, and those
which cannot be automated (i.e., those that must be managed by network
administrators).

 Internet-Drafts:

  No Current Internet-Drafts.


IP Over AppleTalk (appleip)
---------------------------

 Charter

 Current status: active working group

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

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

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

Description of Working Group:

The IP Over AppleTalk Working Group is chartered to facilitate the connection
of Apple Macintoshes to IP internets, and to address the issues of
distributing AppleTalk services in an IP internet.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 92 Feb 94  <draft-ietf-appleip-mib2-02.txt>
                AppleTalk Management Information Base II


IP Over Asynchronous Transfer Mode (ipatm)
------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Mark Laubach <[e-mail]>

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           Send message to [e-mail]

Description of Working Group:

The IP Over Asynchronous Transfer Mode Working Group will focus on
the issues involved in running internetworking protocols over
Asynchronous Transfer Mode (ATM) networks.  The final goal for the
working group is to produce standards for the TCP/IP protocol suite,
and recommendations which could be used by other internetworking
protocol standards (e.g., ISO, CLNP and IEEE 802.2 Bridging).

The working group will initially develop experimental protocols for
encapsulation, multicasting, addressing, address resolution, call set
up, and network management to allow the operation of internetwork
protocols over an ATM network.  The working group may later submit
these protocols for standardization.

The working group will not develop physical layer standards for ATM.
These are well covered in other standards groups and do not need to be
addressed in this group.

The working group will develop models of ATM internetworking
architectures.  This will be used to guide the development of specific IP
over ATM protocols.

The working group will also develop and maintain a list of technical
unknowns that relate to internetworking over ATM.  These will be used
to direct future work of the working group or be submitted to other
standards or research groups as appropriate.

The working group will coordinate its work with other relevant
standards bodies (e.g., ANSI T1S1.5) to insure that it does not
duplicate their work, and that its work meshes well with other
activities in this area.  The working group will select among ATM
protocol options (e.g., selection of an adaptation layer) and
make recommendations to the ATM standards bodies regarding the
requirements for internetworking over ATM where the current ATM
standards do not meet the needs of internetworking.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 94 Jul 94  <draft-ietf-ipatm-sig-01.txt>
                ATM Signaling Support for IP over ATM


Internet Stream Protocol V2 (st2)
---------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Lou Berger <[e-mail]>
     Luca Delgrossi <[e-mail]>

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ibminet.awdpa.ibm.com:~/pub/st/st-archive

Description of Working Group:

The Internet Stream Protocol V2 Working Group was formed to clarify and refine
the existing specification of the Stream Protocol, Version 2 (ST-II)
contained in RFC 1190.  Since ST-II is a protocol that is already used in
audio-visual and reserved-resource applications and services, the focus
of this group is near-term, and its primary purpose is to provide a
specification that corrects errors in the existing ST-II specification and
makes it easier to implement ST-II in a manner that is likely to be
interoperable with other ST-II implementations.

The group intends to address several areas of the ST-II
specification, including:

 a) the formal definition of states and state transitions;

 b) the removal of mechanisms which are too complicated as currently
    designed and which have not shown any use in practice;

 c) address the ambiguities caused by the current implementation
    subsets;

 d) definition of a clear IP encapsulation mechanism;


 e) minor revisions suggested by experience with ST-II.

These modifications are expected to reduce implementation time and to
improve the utility and interoperability of existing and future ST-II
implementations.  The working group may also provide guidance on the
use of standard routing protocols to support ST-II, and on the format and
use of flow specifications.  Finally, particular attention will be
given to the specification of groups of streams as required for the
efficient sharing of resources.  Input from current ST-II developers and
application developers will be solicited to help clarify issues that
the working group should address.

It is the goal of the group to produce a refined ST-II
specification that can be used to rapidly satisfy operational
requirements.  The result of this group is expected to be an
Experimental RFC.  It is not the intention of this working group to
define a new communication or resource reservation protocol.  ST-II is
part of the ongoing IETF efforts to develop protocols that address
resource reservation issues.  It is possible that future IETF working
groups will produce other operational protocol options in this area.
Related work by other IETF working groups shall be carefully monitored
to see if the actions of this Working Group should be revised.  In
particular it is expected that there will be interaction with the AVT
Working Group relating to issues of running RTP over ST-II.


 Internet-Drafts:

  No Current Internet-Drafts.


Point-to-Point Protocol Extensions (pppext)
-------------------------------------------

 Charter

 Current status: active working group

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

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     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>
------ ------- ------------------------------------------
 Mar 93 Apr 94  <draft-ietf-pppext-frame-relay-03.txt>
                PPP in Frame Relay

 Sep 93 May 94  <draft-ietf-pppext-multilink-09.txt>
                The PPP Multilink Protocol (MP)

 Sep 93 Jun 94  <draft-ietf-pppext-netbios-fcp-05.txt>
                The PPP NetBIOS Frames Control Protocol (NBFCP)

 Oct 93 Sep 94  <draft-ietf-pppext-stacker-02.txt>
                PPP Stacker LZS Compression Protocol

 Oct 93 Mar 94  <draft-ietf-pppext-compression-04.txt>
                The PPP Compression Control Protocol (CCP)

 Oct 93 New     <draft-ietf-pppext-gandalf-00.txt>
                PPP Gandalf FZA Compression Protocol

 Oct 93 New     <draft-ietf-pppext-hpppc-00.txt>
                PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC)
                Protocol

 Dec 93 New     <draft-ietf-pppext-predictor-00.txt>
                PPP Predictor Compression Protocol

 Jan 94 Sep 94  <draft-ietf-pppext-bsd-compress-02.txt>
                PPP BSD Compression Protocol

 Feb 94 Sep 94  <draft-ietf-pppext-dataencap-03.txt>
                PPP LCP Option for Data Encapsulation Selection

 Mar 94 New     <draft-ietf-pppext-gap-auth-00.txt>
                The Generic Athentication Protocol (GAP)

 Mar 94 New     <draft-ietf-pppext-aha-auth-00.txt>
                The Arbitrary Handshake Authentication (AHA) protocol

 Mar 94 May 94  <draft-ietf-pppext-magnalink-01.txt>
                PPP Magnalink Variable Resource Compression

 Mar 94 New     <draft-ietf-pppext-kap-auth-00.txt>
                PPP Kerberos Authentication Protocol (KAP)

 Apr 94 Jul 94  <draft-ietf-pppext-callback-cp-02.txt>
                Proposal for Callback Control Protocol (CBCP).

 Jul 94 New     <draft-ietf-pppext-atcp2-00.txt>
                The PPP AppleTalk Control Protocol (ATCP)

 Jul 94 New     <draft-ietf-pppext-vines-00.txt>
                The PPP Banyan Vines Control Protocol (BVCP)

 Jul 94 New     <draft-ietf-pppext-kapv4-auth-00.txt>
                PPP Kerberos version 4 Authentication Protocol (KAPv4)


Router Requirements (rreq)
--------------------------

 Charter

 Current status: active working group

 Chair(s):
     Frank Kastenholz <[e-mail]>
     Bill Manning <[e-mail]>

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

 Area Advisor
     Stev Knowles  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.sesqui.net:/pub/rreq

Description of Working Group:

The Router Requirements Working Group has the goal of publishing the
existing draft as an Historic RFC, then updating it to include
references to more recent work, such as OSPF, BGP, multicast, etc.
Unlike other groups, this is recognized as an on-going effort that
should result in a series of drafts. It is expected that a revised
requirements draft will be published on a regular basis.

The working group will also instigate, review, or (if appropriate)
produce additional RFCs on related topics.  To date, group members have
produced draft documents discussing the operation of routers which are in
multiple routing domains (3 papers), TOS, and a routing table MIB.

The purposes of this project include:

- Defining what an IP router does in sufficient detail that
  routers from different vendors are truly interoperable.

- Providing guidance to vendors, implementors, and purchasers of
  IP routers.

The working group has decided that, unlike RFC 1009, the Router Requirements
document should not discuss link layer protocols or address resolution.
Instead, those topics should be covered in a separate Link Layer Requirements
document, applicable to hosts as well as routers.  Whether this group will
create the Link Layer Requirements document is still to be determined.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jan 94 Apr 94  <draft-ietf-rreq-iprouters-require-01.txt>
                Requirements for IP Routers


Service Location Protocol (svrloc)
----------------------------------

 Charter

 Current status: active working group

 Chair(s):
     John Veizades <[e-mail]>
     Scott Kaplan <[e-mail]>

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

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

Description of Working Group:

The Service Location Protocol Working Group is chartered to investigate
protocols to find, and bind to, service entities in a distributed internetworked
environment.  Issues that must be addressed are how such a protocol would
interoperate with existing directory-based service location protocols.
Protocols that would be designed by this group would be viewed as an adjunct
to directory service protocols.  These protocols would be able to provide a
bridge between directory services and current schemes for service location.

The nature of the service location problem is investigative in
principle.  There is no mandate that a protocol be drafted as part
of this process.  It is the mandate of this group to understand the operation
of service location and then determine the correct action in their view,
whether it be to use current protocols to suggest a service location
architecture, or to design a new protocol to compliment current architectures.



 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 Jul 94  <draft-ietf-svrloc-protocol-04.txt>
                Service Location Protocol


TCP/UDP Over CLNP-Addressed Networks (tuba)
-------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Mark Knopper <[e-mail]>
     Peter Ford <[e-mail]>

 Internet Area Director(s):
     Stev Knowles  <[e-mail]>
     Claudio Topolcic  <[e-mail]>

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

Description of Working Group:

The TUBA Working Group will work on extending the Internet Protocol
suite and architecture by increasing the number of end-systems which
can be effectively addressed and routed.  The TUBA effort will expand
the ability to route Internet packets by using addresses which support
more hierarchy than the current Internet Protocol (IP) address space.
TUBA specifies the continued use of Internet transport protocols, in
particular TCP and UDP, but specifies their encapsulation in ISO 8473
(CLNP) packets.  This will allow the continued use of Internet
application protocols such as FTP, SMTP, TELNET, etc. An enhancement
to the current system is mandatory due to the limitations of the
current 32-bit IP addresses.  TUBA seeks to upgrade the current system
by a transition from the use of IPv4 to
ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access
Point address space.

In addition to protocol layering issues and ``proof of concept'' work,
the TUBA approach will place significant emphasis on the engineering
and operational requirements of a large, global, multilateral public
data network.  TUBA will work to maximize interoperatability with the
routing and addressing architecture of the global CLNP infrastructure.
The TUBA Working Group will work closely with the IETF NOOP and
OSI IDRP for IP Over IP Working Groups to coordinate a viable CLNP-based
Internet which supports the applications which Internet users depend on
such as TELNET, FTP, SMTP, NFS, X, etc.  The TUBA Working Group will also
work collaboratively with communities which are using CLNP, and will
consider issues such as interoperability,
applications coexisting on top of multiple transports, and the
evolution of global public connectionless datagram networks, network
management and instrumentation using CLNP and TUBA, and impact on
routing architecture and protocols given the TUBA transition.

The TUBA Working Group will consider how the TUBA scheme will support
transition from the current IP address space to the future NSAP
address space without discontinuity of service, although different
manufacturers, service providers, and sites will make the transition
at different times. In particular, the way in which implementations
relying on current 32-bit IP addresses will migrate must be
considered.  TUBA will ensure that IP addresses can be assigned, for
as long as they are used, independently of geographical and routing
considerations. One option is to embed IP addresses in NSAP addresses,
possibly as the NSAP end-system identifier. Whatever scheme is chosen
must run in a majority of *-GOSIPs and other NSAP spaces. The TUBA
strategy will require a new mapping in the DNS from NAMEs to NSAP
addresses.

The rationale RFC (RFC 1347) documents issues of transition and
coexistence, among unmodified IPv4 hosts and hosts which support
TUBA hosts.  Hosts wishing full Internet connectivity will need to
support TUBA.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 94 May 94  <draft-ietf-tuba-host-clnp-multicas-01.txt>
                Host Group Extensions for CLNP Multicasting

 Mar 94 Jul 94  <draft-ietf-tuba-transition-01.txt>
                Transition Plan for TUBA/CLNP

 Mar 94 New     <draft-ietf-tuba-eon-00.txt>
                Tunneling the OSI Network Layer over IP (EON)

 Mar 94 New     <draft-ietf-tuba-sysid-00.txt>
                Suggested System ID Option for the ES-IS Protocol

 Mar 94 New     <draft-ietf-tuba-addr-assign-00.txt>
                Dynamic Assignment of OSI NSAP Addresses in the Internet

 May 94 Jun 94  <draft-ietf-tuba-mtu-01.txt>
                CLNP Path MTU Discovery

 May 94 New     <draft-ietf-tuba-inlsp-00.txt>
                Integrated Network Layer Security Protocol For TUBA

 May 94 New     <draft-ietf-tuba-mobility-00.txt>
                TUBA Mobility Support

 Jul 94 New     <draft-ietf-tuba-mib-00.txt>
                Extensions to MIB-II for TUBA/CLNP systems


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

 Charter

 Current status: active working group

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

 Network Management Area Director(s):
     Marshall Rose  <[e-mail]>

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

Description of Working Group:

     The Interfaces MIB Working Group is chartered to accomplish two tasks.

     First, to develop a collection of managed objects which model the
     relation between different entities in the data link and physical
     layers.  The working group will explore different modeling
     approaches in order to develop a collection of objects which is
     both correct in the modeling sense and has an acceptable impact (if
     any) on the interfaces table from MIB-II and all media MIB modules
     on the standards track or under development by a working group.
     The objects defined by the working group will be consistent with
     the SNMP framework.

     Second, to prepare a recommendation to the IESG evaluating RFC 1229
     (the interface-extensions MIB), RFC 1231 (the token-ring MIB), RFC 1304
     (the SMDS MIB), and RFC 1398 (the ethernet-like MIB) with respect to the
     standards track.

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

     For RFCs 1229, 1231, and 1304, the recommendation will report one
     of four outcomes for each RFC:

    - that the RFC should be advanced from Proposed to Draft Standard status,
    without changes (if no problems are found);

    -that a draft prepared by the working group should replace
    the RFC, and be designated a Draft Standard (if only minor changes
    are made);

    - that a draft prepared by the working group should
    replace the RFC, and be designated a Proposed Standard (if major
    changes or feature enhancements are made); or,

    - that the RFC should be designated as Historic (if this technology
    is problematic).

     For RFC 1398, the recommendation will report one of five outcomes:

     - that the RFC should be advanced from Draft Standard to Standard
      status, without
     changes (if no problems are found);

     - that a draft prepared by the
     working group should replace the RFC, and be designated a
     Standard (if only editorial changes are made);

     - that a draft
     prepared by the working group should replace the RFCs, and be
     designated a Draft Standard (if only minor changes are made);

     - that
     a draft prepared by the working group should replace the RFC, and
     be designated a Proposed Standard (if major changes or feature
     enhancements are made); or,

     - that the RFC should be designated as
     Historic (if this technology is problematic).


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 Jul 94  <draft-ietf-ifmib-conntable-02.txt>
                Management Information Base for Management of Network
                Connections

 Jul 94 New     <draft-ietf-ifmib-tokenringmib-00.txt>
                IEEE 802.5 MIB

 Sep 94 New     <draft-ietf-ifmib-ssr-mib-00.txt>
                IEEE 802.5 Station Source Routing MIB


Printer MIB (printmib)
----------------------

 Charter

 Current status: active working group

 Chair(s):
     Joel Gyllenskog <[e-mail]>

 Network Management Area Director(s):
     Marshall Rose  <[e-mail]>

 Area Advisor
     Steven Waldbusser  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftpboi.external.hp.com:/pub/snmpmib

Description of Working Group:

The Printer MIB Working Group is chartered to develop a set of managed
objects for networked printers. These objects will be the minimum
necessary to provide the ability to monitor and control these systems,
providing fault, configuration and performance management, and will be
consistent with the SNMP framework and existing SNMP standards.

At its discretion, the working group may also define a small number of
unsolicited notifications (traps) which carry these managed objects.
However, the working group recognizes that traps are used sparingly in
the SNMP framework.

The working group recognizes that the area of networked printers is
quite diverse. However, the working group is specifically confined to
defining managed objects that instrument critical information about:

- printer engine

- interpreters

- media

- input sources

- output destinations

- I/O interfaces

Further, the working group is specifically prohibited from defining
managed objects that define instrumentation about:

- other marking technologies (e.g., those that mark onto film)

- fonts

- spooling

- print job management

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 94 Aug 94  <draft-ietf-printmib-printer-mib-03.txt>
                Printer MIB


Remote Network Monitoring (rmonmib)
-----------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Mike Erlinger <[e-mail]>

 Network Management Area Director(s):
     Marshall Rose  <[e-mail]>

 Area Advisor
     Steven Waldbusser  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           jarthur.cs.hmc.edu:/pub/rmon

Description of Working Group:

The RMON MIB Working Group is chartered to define a set of managed
objects for remote monitoring of networks.  These objects will be
the minimum necessary to provide the ability to monitor multiple
network layers of traffic in remote networks; providing fault,
configuration, and performance management, and will be consistent
with the SNMP framework and existing SNMP standards.

The working group will consider existing MIB modules that define
objects which support similar management, e.g., RFC 1271 and
RFC 1513 and efforts in other areas, e.g., the accounting and
operational statistics activities.  It is possible that this RMON
will not be backwards compatible with existing RMON RFCs, but the
reasons for any such incompatibility will be well documented.

The following list of features for this RMON has been previously
discussed in relation to existing RMON functionality and is included
to focus these RMON activities.  It is recognized that other issues
may be considered and that certain of the following issues may not
be part of the final specification:

1) Protocol-type distribution through all seven layers of the ISO
   model.

2) Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa.

3) Mechanisms that enable the detection of duplicate addresses or
   address changes.

4) The relationship of the Manager-to-Manager MIB in SNMPv2 and
   associated RMON alarm related activities.

5) Host Table for the Network Layer and the Transport Layer.

6) Provide a simple mechanism for the specification of event/trap
   destinations

7) Address the issue of the filter mechanism being constrained by
   bit-to-bit packet matching, which presents a problem with variable-
   length packets.

8) Consider how RMON could benefit network security, for example:
   using the RMON History to provide an accountability and audit
   trail up to the Transport Layer.

9) Provide performance metrics for the client-server environment.

10) Concerns of hardware implementation should be considered.  For example,
   optimization of the filter and capture group could reduce the cost of
   the CPU and improve performance.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 94 Jun 94  <draft-ietf-rmonmib-rmonmib-02.txt>
                Remote Network Monitoring Management Information Base


SNA DLC Services MIB (snadlc)
-----------------------------

 Charter

 Current status: active working group

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

 Network Management Area Director(s):
     Marshall Rose  <[e-mail]>

 Area Advisor
     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:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 Jun 94  <draft-ietf-snadlc-sdlc-mib-04.txt>
                Definitions of Managed Objects for SNA Data Link Control: SDLC

 Jul 94 New     <draft-ietf-snadlc-llc-mib-00.txt>
                Definitions of Managed Objects for SNA Data Link Control: LLC


SNA NAU Services MIB (snanau)
-----------------------------

 Charter

 Current status: active working group

 Chair(s):
     Zbigniew Kielczewski <[e-mail]>
     Deirdre Kostick <[e-mail]>

 Network Management Area Director(s):
     Marshall Rose  <[e-mail]>

 Area Advisor
     David Perkins  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           thumper.bellcore.com:pub/tob/snanaumib/archive

Description of Working Group:

     The SNA NAU Services MIB Working Group is chartered to define a
     set of managed objects for PU type 2.1 LEN nodes and LU type 6.2
     devices for SNA networks.  These objects will be the minimum
     necessary to provide the ability to monitor and control those
     devices, providing fault, configuration, and performance
     management, and will be consistent with the SNMP framework and
     existing SNMP standards.

     The working group will consider existing enterprise-specific MIB
     modules that define objects which support management of these
     devices.  It will also make sure that its work is aligned with the
     SNA DLC Services MIB Working Group, due to the close relationship
     between the devices being worked on by the two groups.

     The working group recognizes that managed objects for other
     components may need to be identified in the future.  For example,
     APPN end and network nodes are not included. These objects are out
     of scope for the current charter; however, once the group
     completes its charter, a new charter identifying some or all of
     these components may be considered.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 94 New     <draft-ietf-snanau-appcmib-00.txt>
                Definitions of Managed Objects for APPC


Process for Organization of Internet Standards (poised)
-------------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Steve Crocker <[e-mail]>
     Mel Pleasant <[e-mail]>

 None Director(s):
     Paul Mockapetris  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/*

Description of Working Group:


In 1992 and 1993, the POISED effort revised the responsibilities of
the IESG and IAB and instituted a selection process for filling
positions on these bodies.  The ISOC Trustees gave interim approval
to these arrangements and asked that we revisit, revise and formalize
the arrangements after two rounds of selection had been completed.
The POISED Working Group will now review the current rules, propose
charters and rules for the IESG, IETF, IAB, IRSG, and IRTF, and submit
them to the ISOC Trustees after approval by the IETF.

There appears to be general consensus that the current assignments of
responsibility and the selection process are working moderately well,
so it is not anticipated that there will be large changes.
Nonetheless, some issues have been raised and need review.  Among
these are:

o There is a complex interplay between the IETF area structure and the
  selection process for the IESG.  The IESG has the power to create,
  split, merge and remove areas, but the nominations committee has the
  responsibility to fill positions.  The IESG needs some flexibility
  to balance work loads, use its people effectively, and meet the
  changing needs of the IETF.  The current rules are not completely
  clear as to how to handle all of the likely situations; these need to
  be spelled out and agreed to.

o The nominations committee has non-voting liaisons from the IESG and
  IAB.  Both nominations committees also had current IAB or IESG
  members, who volunteered and were selected at random, as voting
  members.  It has been suggested that current IESG and IAB members
  carry too much weight in the deliberations and should be barred from
  serving on the nominations committee.

o The selection and role of the nominations committee chair is somewhat
  unclear.  In particular, what power does the chair have to deal with
  unresponsive committee members and/or to resolve disputes?

o At what point, if any, does the nominations committee's list of
  candidates become public.  This ties in with the apparent double-
  standard of how publically incumbents vs. non-incumbents announce
  their candidacy.

o The way to handle interim appointments is not clear.  Two specific
  issues are: who appoints interim members (and is ``ratification''
  required), and how long does interim appointees serve?

o When the nominations committee has completed its work, it informs the
  IAB and the ISOC Trustees.  The procedures for doing so need to be
  spelled out.  At issue is when the nominations become public, whether
  the community at large is invited to comment, and what to do if there
  is difficulty in filling any of the positions.

o There is currently no specific mechanism for the IAB to use to
  provide architectural guidance to working groups before the RFC
  submission stage.  POISED may discuss whether such a mechanism is
  necessary, and if so, what that mechanism looks like.

o The role of the IRTF and research groups has not yet been defined.

o Should there be a regular mechanism for convening a POISED Working
  Group in the future?

o The ISOC Trustees require that the procedures adopted meet with the
  approval of counsel and the insurance carriers in order to protect
  the Society from exposure.  The procedures, rules, etc. adopted by
  the community will most likely be satisfactory to counsel, but input
  and review from counsel is essential.

In its deliberations, POISED may produce new documents (e.g., an IETF
Charter -- if the lack of such a charter delays the POISED effort),
and it may request changes to existing documents (e.g., ``The IAB
Charter'' [RFC 1601], ``The Internet Standards Process -- Version 2''
[RFC 1602], and ``IETF Working Group Guidelines and Procedures''
[RFC 1603]).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 94 New     <draft-ietf-poised-nomcomm-00.txt>
                Procedure to Select and Confirm Individuals Serving on the IAB
                and IESG


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

 Charter

 Current status: active working group

 Chair(s):
     Jim McQuaid <[e-mail]>

 Operational Requirements Area Director(s):
     Scott Bradner  <[e-mail]>
     Michael O'Dell  <[e-mail]>

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

Description of Working Group:

The major goal of the Benchmarking Methodology Working Group is to make a
series of recommendations concerning the measurement of the performance
characteristics of different classes of network equipment and software
services.

Each recommendation will describe the class of equipment or service,
discuss the performance characteristics that are pertinent to that
class, specify a suite of performance benchmarks that test the described
characteristics, as well as specify the requirements for common
reporting of benchmark results.

Classes of network equipment can be broken down into two broad
categories.  The first deals with stand-alone network devices such as
routers, bridges, repeaters, and LAN wiring concentrators.  The second
category includes host-dependent equipment and services, such as network
interfaces or TCP/IP implementations.

Once benchmarking methodologies for stand-alone devices have matured
sufficiently, the group plans to focus on methodologies for testing
system-wide performance, including issues such as the responsiveness of
routing algorithms to topology changes.

 Internet-Drafts:

  No Current Internet-Drafts.


CIDR Deployment (cidrd)
-----------------------

 Charter

 Current status: active working group

 Chair(s):
     Jessica Yu <[e-mail]>
     Vince Fuller <[e-mail]>

 Operational Requirements Area Director(s):
     Scott Bradner  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu: ~/pub/bgpd-archive

Description of Working Group:

The CIDR Deployment Working Group will be a forum for
coordinating the deployment, engineering, and operation of classless
routing protocols and procedures in the global Internet. This activity
will include, but not be limited to:

  - Deployment of CIDR addressing and routing in the global Internet.
     Will include coordination of deployment of new exterior routing
     protocols, such as BGP4, which support CIDR.

  - Develop mechanisms and procedures for sharing operational
    information to aim the operation.

  - Development of procedures, policies, and mechanisms to improve
    the utilization efficiency of the IPv4 address space.

  - Work on longer-term strategies for hierarchical, CIDR-based
    addressing and routing. Examples include class A subnetting and
    provider block sub-allocation along geographical/topological
    boundaries as is done for 193.0.0.0 and 194.0.0.0 in Europe.

Initially, this working group will be simply the reincarnation of the
BGP Deployment Working Group under a new name.

 Internet-Drafts:

  No Current Internet-Drafts.


Generic Internet Service Description (gisd)
-------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     David Sitman <[e-mail]>

 Operational Requirements Area Director(s):
     Scott Bradner  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe gisd-wg
     Archive:           ftp://ftp.ripe.net/ripe/archives/gisd-wg/current

Description of Working Group:

GISD collects short descriptions of Internet service aspects.  Internet
service in GISD means the interaction of Internet service providers
among themselves and with their users.  GISD aims to provide a
common frame of reference and vocabulary to talk about an Internet
service.  For each aspect of the Internet service, it describes different
options for service provision in use in the current Internet.  GISD is
merely descriptive and does not proscribe or mandate.  The GISD document is
intended to be a living document, collecting the work of many contributors.

The GISD Working Group will update and revise the GISD document to
assist network service providers in a better understanding and description
of what Interent service means.

- Update and revise the GISD document that lists the areas and aspects of
  interest to TCP/IP network service providers.

- Identify additional GISD areas and aspects appropriate to GISD.

- Identify areas of overlap with other IETF working groups.

- Create a reference document of GISD terms.

- Establish procedures to ensure the ongoing maintenance of the document
  and identify an organization willing to do it.

 Internet-Drafts:

  No Current Internet-Drafts.


Network Status Reports (netstat)
--------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Gene Hastings <[e-mail]>

 Operational Requirements Area Director(s):
     Scott Bradner  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Mailing lists:
     General Discussion:
     To Subscribe:
     Archive:

Description of Working Group:

  The Network Status Reports Working Group reports on the status
  of various parts of the Internet.  The group is semi-pertinent,
  and therefore does not have goals and milestones like other
  working groups do.

 Internet-Drafts:

  No Current Internet-Drafts.


Operational Statistics (opstat)
-------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Henry Clark <[e-mail]>
     J. Nevil Brownlee <[e-mail]>

 Operational Requirements Area Director(s):
     Scott Bradner  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           wuarchive.wustl.edu:~doc/mailing-lists/oswg-l

Description of Working Group:

Today  there exists a  variety of network  management tools for
the collection and presentation  of network statistical  data.
Different kinds  of measurements  and  presentation techniques
make it hard to compare data between networks.  There exists a
need to compare these statistical data on  a uniform  basis to
facilitate cooperative management,  ease problem isolation  and
network planning.

The working group will  try  to   define a  model for  network
statistics,   a minimal set   of  common  metrics,   tools for
gathering  statistical  data, a  common  statistical  database
storage format and  common presentation   formats.  Collecting
tools will store data in a given  format later to be retrieved
by presentation tools displaying the data in a predefined way.


 Internet-Drafts:

  No Current Internet-Drafts.


IP Routing for Wireless/Mobile Hosts (mobileip)
-----------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Kannan Alagappan <[e-mail]>
     Greg Minshall <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           loki.ossi.com:/pub/mobile-ip/

Description of Working Group:

The Mobile IP Working Group is chartered to develop or adopt
architectures and protocols to support mobility within the Internet.
In the near-term, protocols for supporting transparent host ``roaming''
among different subnetworks and different media (e.g., LANs, dial-up
links, and wireless communication channels) shall be developed and
entered into the Internet standards track.  The work is expected to
consist mainly of new and/or revised protocols at the (inter)network
layer, but may also include proposed modifications to higher-layer
protocols (e.g., transport or directory).  However, it shall be a
requirement that the proposed solutions allow mobile hosts to
interoperate with existing Internet systems.

In the longer term, the group may address, to the extent not covered by the
mobile host solutions, other types of internet mobility, such as
mobile subnets (e.g., a local network within a vehicle), or mobile
clusters of subnets (e.g., a collection of hosts, routers, and subnets
within a large vehicle, like a ship or spacecraft, or a collection of
wireless, mobile routers that provide a dynamically changing internet
topology).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 94 Sep 94  <draft-ietf-mobileip-protocol-06.txt>
                IP Mobility Support

 Mar 94 New     <draft-ietf-mobileip-integrated-00.txt>
                Integrated Mobility Extension

 Mar 94 New     <draft-ietf-mobileip-addr-ext-00.txt>
                Local Care-Of Address Extension


IS-IS for IP Internets (isis)
-----------------------------

 Charter

 Current status: active working group

 Chair(s):
     Ross Callon <[e-mail]>
     Chris Gunner <[e-mail]>

 Routing Area Director(s):
     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:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 91 Jul 94  <draft-ietf-isis-mib-04.txt>
                Integrated IS-IS Management Information Base

 Jan 93 Jul 94  <draft-ietf-isis-tcpip-01.txt>
                Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol
                Environments

 Mar 94 Jul 94  <draft-ietf-isis-prot-anal-01.txt>
                Integrated ISIS Protocol Analysis

 Mar 94 Jul 94  <draft-ietf-isis-opexp-01.txt>
                Experience with the Integrated ISIS Protocol


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

 Charter

 Current status: active working group

 Chair(s):
     Tony Ballardie <[e-mail]>
     Paul Francis <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           cs.ucl.ac.uk:/darpa/idmr-archive.Z

Description of Working Group:

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

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

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 94 New     <draft-ietf-idmr-pim-dense-spec-00.txt>
                Protocol Independent Multicast (PIM), Dense Mode Protocol
                Specification

 Mar 94 New     <draft-ietf-idmr-pim-arch-00.txt, .ps>
                Protocol Independent Multicast (PIM): Motivation and
                Architecture

 Mar 94 New     <draft-ietf-idmr-pim-sparse-spec-00.txt, .ps>
                Protocol Independent Multicast (PIM), Sparse Mode Protocol
                Specification

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

 Jul 94 New     <draft-ietf-idmr-multicast-routmib-00.txt>
                IP Multicast Routing MIB

 Jul 94 New     <draft-ietf-idmr-pim-mib-00.txt>
                Protocol Independent Multicast MIB


Inter-Domain Policy Routing (idpr)
----------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Martha Steenstrup <[e-mail]>

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

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

Description of Working Group:

The Inter-Domain Policy Routing Working Group is chartered to
develop an architecture and set of protocols for policy routing
among large numbers of arbitrarily interconnected administrative
domains.

 Internet-Drafts:

  No Current Internet-Drafts.


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

 Charter

 Current status: active working group

 Chair(s):
     Sue Hares <[e-mail]>
     Yakov Rekhter <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:/pub/archive/bgp

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 over IPv4 (standards track)

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

4) IDRP MIB (standards track)

   This document contains the MIB definitions for IDRP.

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

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

6) BGP/IDRP for IPv4 Usage (standards track)

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

7) IDRP for IPv6

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

8) IDRP for IP Next Generation Usage

   The IDRP for IPv6 Usage document will contain instructions on
   how to run IDRP for IPv6 over IPv4 and IPv6.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 92 Aug 94  <draft-ietf-idr-bgp4ospf-interact-07.txt>
                BGP4/IDRP for IP---OSPF Interaction

 Aug 94 New     <draft-ietf-bgp-autosys-guide-00.txt>
                Guidelines for creation, selection, and registration of an
                Autonomous System (AS)


Multicast Extensions to OSPF (mospf)
------------------------------------

 Charter

 Current status: active working group

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

 Routing Area Director(s):
     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.


New Internet Routing and Addressing Architecture (nimrod)
---------------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     J. Noel Chiappa <[e-mail]>
     Isidro Castineyra <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           bbn.com:/pub/nimrod-wg/nimrod-wg.archive

Description of Working Group:

The goal of the working group is to design, specify, implement and test a
flexible new routing and addressing architecture suitable for very large
scale internets.  The basic architecture for computation of routes will
be based on distribution of network topology maps, with source-specified
route selection, and unitary (i.e., not hop-by-hop) computation of routes.

The architecture will provide a single homogeneous framework for all
routing, including both inter-domain and intra-domain.  It will include a
new network component naming abstraction hierarchy, starting from network
attachment points, and based on actual connectivity, but taking into
consideration policy requirements.  These new names will be variable
length, with a variable number of levels of abstraction; they will not
appear in most packets, though.

Actual packet forwarding will be based both on retained non-critical
state in the switches (via flow setup for long-lived communications), and
both classical address-only, as well as source-route type instructions, in
individual packets (for datagram applications which send only one, or a very
few, packets).

Although the general design and algorithms will be usable in any
internetworking protocol family, the initial detailed protocol
specifications and implementation are currently planned for deployment
with IPv4, but support for another packet format may be substituted or
added, depending on the situation in the Internet in the future.
Interoperabilty with existing unmodified IPv4 hosts will be achieved by
re-interpreting the existing source and destination fields in IPv4
packets as endpoint identifiers.

A substantial effort to take into account support for mobility,
multicast and resource allocation will be made when designing the Nimrod
architecture; provided that so doing is neither impossible because of
incomplete work outside the scope of Nimrod, nor the cause of very
substantial delays in the first iteration of the protocol design.


 Internet-Drafts:

  No Current Internet-Drafts.


Open Shortest Path First IGP (ospf)
-----------------------------------

 Charter

 Current status: active working group

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

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

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

Description of Working Group:

The OSPF Working Group will develop and field-test an SPF-based
Internal Gateway Protocol.  The specification will be published and
written in such a way so as to encourage multiple vendor
implementations.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 Jul 94  <draft-ietf-ospf-mib-04.txt>
                OSPF Version 2 Management Information Base

 Feb 94 Jul 94  <draft-ietf-ospf-cidr-route-mib-03.txt>
                IP Forwarding Table MIB

 Mar 94 New     <draft-ietf-ospf-pmp-if-00.txt>
                OSPF Point-to-MultiPoint Interface

 May 94 New     <draft-ietf-ospf-demand-00.txt>
                Extending OSPF to support demand circuits

 Aug 94 Sep 94  <draft-ietf-ospf-md5-01.txt>
                OSPF MD5 Authentication


RIP Version II (ripv2)
----------------------

 Charter

 Current status: active working group

 Chair(s):
     Gary Malkin <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           xylogics.com:gmalkin/rip/rip-arc

Description of Working Group:

   RIP Version 2 and the Version 2 MIB was approved as a Proposed
   Standard in January 1993.  They were published as RFC 1388 and RFC 1389.
   Since the mimimum required period has elapsed for a protocol
   to remain as a Proposed Standard, RIP V2 can now be considered for
   advancement to Draft Standard.

   The RIP Version 2 Working Group will prepare a recommendation to the
   IESG evalating the standards track status of RIP Version 2 and the
   RIP Version 2 MIB.  The recommendation will document implementation,
   interoperability and deployment experience as required by RFC 1264
   ``Routing Protocol Criteria.''

   This group is chartered to prepare revisions of ``RIP Version 2''
    (RFC 1388), ``RIP Version 2 MIB'' (RFC 1389), and the analysis
    document (RFC 1387) if necessary.

   The RIP Version 2 Working Group is further chartered to evaluate the
   proposal for ``Routing over Demand Circuits using RIP'' for standards
   track consideration.



 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 Jul 94  <draft-ietf-ripv2-protocol-01.txt>
                RIP Version 2 Carrying Additional Information

 Oct 93 Aug 94  <draft-ietf-ripv2-mibext2-02.txt>
                RIP Version 2 MIB Extension

 Dec 93 Apr 94  <draft-ietf-ripv2-protocol-analysis-01.txt>
                RIP Version 2 Protocol Analysis

 Jul 94 Jul 94  <draft-ietf-ripv2-protocol-applic-01.txt>
                RIP Version 2 Protocol Applicability Statement


Routing over Large Clouds (rolc)
--------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Andy Malis <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           cnri.reston.va.us:/ietf-mail-archive/rolc/

Description of Working Group:

Summary: This group is created to analyse and propose solutions to
those problems that arise when trying to perform IP routing over large
``shared media'' networks. Examples of these networks include SMDS, Frame
Relay, X.25, and ATM.

Definition:
   Internetwork Layer: To avoid confusion with multiple meanings of
   ``network'' layer, we will use the term ``Internetwork'' layer to
   unambiguously refer to that layer at which IP runs. This is the
   layer at which IP routing functions. This is also the layer at which
   CLNP, DECnet, etc. run.

Large cloud:  A collection of ``end-points'' be they routers or hosts,
   connected over a fabric such that communication can be established,
   in the absence of policy restrictions, between any two such
   entities. This communication within a cloud takes place using
   addressing and capabilities below the ``Internetwork'' layer.

The connectivity may or may not require circuit setup before
communication. Such a collection is considered large if it is
infeasible for all routing entities on such a ``cloud'' to maintain
``adjacencies'' with all others. Examples include, but are not limited
to, ATM, Frame Relay, SMDS, and X.25 public services.

The group will investigate the operation of IP routing protocols and
services over ``Large Clouds.'' Whenever possible, solutions shall be
applicable to a range of ``cloud'' services. That is, the goal is a
single solution applicable to multiple kinds of large ``clouds'' be they
public or private, and independent of the specific technology used to
realize the ``cloud'' (even a very large bridged Ethernet). It is also an
objective that solutions, where possible, apply to network layer
protocols other than IP.

The problems the group will cover are:

A) The architectural implications of allowing direct communication
   between entities which do not share a common IP network number. The
   group will also entertain proposals on the use of a common IP network
   number. If (as many believe) it is infeasible, an effort to document
   the difficulties will be made.

B) The routing/information protocol required to allow direct
   communication between two entities which were not directly
   exchanging routing information.  This will include address
   resolution.  The solution must couple closely to routing. It must
   take into account realistic connectivity policies.

C) Operation of existing protocols between peers on such clouds. Are
   any changes necessary or desirable?  If changes are required, they will
   be proposed to the relevant working group.

D) Consideration of how policy restrictions and constraints (such as
   access control and policy-based routing paths) affect A, B, and C.

The group will also review the applicability of the work to ISDN and
POTS. These technologies have a prima-facia difference, in that the
number of simultaneous connections is much smaller. The implications of
this for routing and relaying at the Internetwork layer will need to be
explored further.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 Aug 94  <draft-ietf-rolc-nhrp-02.txt>
                NBMA Next Hop Resolution Protocol (NHRP)

 May 94 New     <draft-ietf-rolc-nbma-arp-00.txt>
                NBMA Address Resolution Protocol (NARP)


Source Demand Routing (sdr)
---------------------------

 Charter

 Current status: active working group

 Chair(s):
     Deborah Estrin <[e-mail]>
     Tony Li <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           jerico.usc.edu:~/pub/sdrp

Description of Working Group:

The SDR Working Group is chartered to specify and promote the use of
SDRP (Source Demand Routing Protocol) as an inter-domain routing protocol
capability in conjunction with IDRP and BGP inter-domain routing
protocols.  The purpose of SDR is to support source-initiated selection
of inter-domain routes, to complement the intermediate node selection
provided by BGP/IDRP.

The goal of the SDR Working Group is to release the components of SDR
as IETF Prototypes and to obtain operational experience with SDR in the
Internet.  Once there is enough experience with SDR, the working group
will submit the SDR components to the IESG for standardization.

SDR has four components: packet formats for protocol control messages
and encapsulation of user datagrams, processing and forwarding of user
data and control messages, routing information distribution/collection
and route computation, and configuration and usage.


The group's strategy is to:

(1) Define the format, processing and forwarding of user datagram and
control messages so that SDR can be used very early on as an efficient
means of supporting ``configured'' inter-domain routes.  User packets are
encapsulated along with the source route and forwarded along the
``configured'' route.  Routes are static at the inter-domain level, but
are not static in terms of the intra-domain paths that packets will
take between specified points in the SDR route. The impact of
encapsulation on MTU, ICMP, performance, etc., are among the issues
that must be evaluated before deployment.

(2) Develop simple schemes for collecting dynamic domain-level
connectivity information, and route construction based on this
information, so that those domains that want to can make use of a
richer, and dynamic set of SDR routes.

(3) In parallel with (1) and (2), develop usage and configuration documents
and prototypes that demonstrate the utility of static-SDR and
simple-dynamic-SDR.

(4) After gaining some experience with the simple schemes for
distribution, develop a second generation of information distribution
and route construction schemes.  The group hopes to benefit from discussions
with IDPR and Nimrod developers at this future stage because the issues
faced are similar.

(5) The group will also investigate the addition of security options into the
SDRP forwarding and packet format specifications.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 92 Mar 94  <draft-ietf-sdr-sdrp-04.txt>
                Source Demand Routing:  Packet Format and Forwarding
                Specification (Version 1).

 Jul 94 New     <draft-ietf-sdr-route-construction-00.txt, .ps>
                SDRP Route Construction


Authorization and Access Control (aac)
--------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Clifford Neuman <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           prospero.isi.edu:~/pub/aac/*

Description of Working Group:

     The goal of the Authorization and Access Control Working Group
     is to develop guidelines and an Application Programming Interface
     (API) through which network accessible applications can uniformly
     specify access control information.  This API will allow applications
     to make access control decisions when clients are not local users,
     might not be members of a common organization, and often not known to
     the service or application in advance.

     Several authentication mechanisms are in place on the Internet, but
     most applications are written with local applications in mind and no
     guidelines exist for supporting authorization and access control based
     on the output of such authentication mechanisms.  The CAT Working
     Group developed the GSS-API, a common API to support authentication.
     The AAC Working Group will develop a common API that accepts the
     identity of a client (perhaps the output of the GSS-API), a reference
     to an object to be accessed, and optionally an indication of the
     operation to be performed.  The API will return a list of authorized
     operations or a yes/no answer that can be easily used by the
     application.

     A second, longer term purpose of the working group will be to
     examine evolving mechanisms and architectures for authorization in
     distributed systems and to establish criteria which enable
     interworking of confidence and trust across systems.  The working
     group will develop additional goals and milestones related to
     this purpose and will submit a revised charter once the appropriate
     goals and milestones are determined.  To the extent possible this
     additional work will encourage evolution toward credential formats
     that more readily allow support for or translation across multiple
     mechanisms.

 Internet-Drafts:

  No Current Internet-Drafts.


Commercial Internet Protocol Security Option (cipso)
----------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Ron Sharp <[e-mail]>

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

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

Description of Working Group:

The Commercial Internet Protocol Security Option Working Group is
chartered to define an IP security option that can be used to pass security
information within and between security domains.  This new security option
will be modular in design to provide developers with a single software
environment which can support multiple security domains.

The CIPSO protocol will support a large number of security domains.  New
security domains will be registered with the Internet Assigned Numbers
Authority (IANA) and will be available with minimal difficulty to all
parties.

There is currently in progress another IP security option referred to as
IPSO (RFC 1108).  IPSO is designed to support the security labels used by
the US Department of Defense.  CIPSO will be designed to provide labeling for
the commercial, US civilian and non-US communities.

The Trusted Systems Interoperability Group (TSIG) has developed a document
which defines a structure for the proposed CIPSO option.  The working group
will use this document as a foundation for developing an IETF CIPSO
specification.



 Internet-Drafts:

  No Current Internet-Drafts.


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

 Charter

 Current status: active working group

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

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

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

Description of Working Group:

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

In support of these goals, the working group will pursue several
interrelated tasks.  We will work towards agreement on a common
service interface allowing callers to invoke security services, and
towards agreement on a common authentication token format,
incorporating means to identify the mechanism type in conjunction with
which authentication data elements should be interpreted.  The CAT
Working Group will also work towards agreements on suitable underlying
mechanisms to implement security functions; two candidate
architectures (Kerberos V5, based on secret-key technology and
contributed by MIT, and X.509-based public-key Distributed
Authentication Services being prepared for contribution by DEC) are
under current consideration.  The CAT Working Group will consult with
other IETF working groups responsible for candidate caller protocols,
pursuing and supporting design refinements as appropriate.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 93 May 94  <draft-ietf-cat-ftpsec-05.txt>
                FTP Security Extensions

 Mar 94 Jul 94  <draft-ietf-cat-kerb5gss-01.txt>
                The Kerberos Version 5 GSS-API Mechanism

 Jul 94 New     <draft-ietf-cat-spkmgss-00.txt>
                The Simple Public-Key GSS-API Mechanism (SPKM)


DNS Security (dnssec)
---------------------

 Charter

 Current status: active working group

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

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

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

Description of Working Group:

The Domain Name System Security Working Group (DNSSEC) will
specify enhancements to the DNS protocol to protect the DNS against
unauthorized modification of data and against masquerading of data
origin.  That is, it will add data integrity and authentication
capabilities to the DNS.  The specific mechanism to be added to the DNS
protocol will be a digital signature.

The digital signature service will be added such that the DNS resource
records will be signed and, by distributing the signatures with the
records, remote sites can verify the signatures and thus have
confidence in the accuracy of the records received.

There are at least two issues to be explored and resolved.  First,
should the records be signed by the primary or secondary (or both)
servers distributing the resource records, or should they be signed by
the start of authority for the zone of the records.  This issue is
relevant since there are servers for sites that are not IP connected.
Second, the mechanism with which to distribute the public keys
necessary to verify the digital signatures must be identified.

Two essential assumptions have been identified.  First, backwards
compatibility and co-existence with DNS servers and clients that do not
support the proposed security services is required.  Second, data in
the DNS is considered public information.  This latter assumption means
that discussions and proposals involving data confidentiality and
access control are explicitly outside the scope of this working group.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 94 Mar 94  <draft-ietf-dnssec-secext-01.txt>
                Domain Name System Protocol Security Extensions


Internet Protocol Security Protocol (ipsec)
-------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     James Zmuda <[e-mail]>
     Paul Lambert <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.ans.net:~/pub/archive/ipsec

Description of Working Group:

Rapid advances in communication technology have accentuated the need
for security in the Internet.  The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP.
A security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.  The
protocol formats for the IP Security Protocol (IPSP) will be independent of
the cryptographic algorithm.  The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and
host-to-subnet topologies.

Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security.  The key
management will be specified as an application layer protocol that is
independent of the lower layer security protocol.  The protocol will
initially support public key-based techniques.  Flexibility in the
protocol will allow eventual support of Key Distribution Center (KDC -
such as Kerberos) and manual distribution approaches.

 Internet-Drafts:

  No Current Internet-Drafts.


Network Access Server Requirements (nasreq)
-------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Allan Rubens <[e-mail]>
     John Vollbrecht <[e-mail]>

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

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:/pub/nas-req-archive

Description of Working Group:


The Network Access Server Requirements Working Group has as its primary
goal, to identify functions and services that should be present in IP
Network Access Servers (NASs) and to specify the standards that
provide for these functions and services.  The term ``Network Access
Server'' is used instead of the more conventional term ``Terminal Server''
as it more accurately describes the functions of interest to this
group.  A ``Network Access Server'' is a device that provides for the
attachment of both traditional ``dumb terminals'' and terminal emulators
as well as workstations, PCs or routers utilizing a serial line
framing protocol such as PPP or SLIP.  A NAS is viewed as a device that
sits on the boundary of an IP network, providing serial line points of
attachment to the network.  A NAS is not necessarily a separate
physical entity; for example, a host system supporting serial line
attachments is viewed as providing NAS functionality and should abide
by NAS requirements.

This group will adopt (or define, if need be) a set of standard
protocols to meet the needs of organizations providing network access.
The immediate needs to be addressed by the group are in the areas of
authentication, authorization, and accounting. In general, this
group will select a set of existing standards as requirements for a
NAS.  If necessary, the group will identify areas of need where
Internet standards do not already exist and new standardization efforts
may be required.

Initially the group will independently investigate the two cases of
character and frame-oriented access to the NAS.  This investigation
will be aimed at determining what work is being done, or needs to be
done, in this and other working groups in order to be able to define
the set of NAS requirements.  While the ultimate goal of this group is
to produce a NAS requirements document, it may be necessary to define
standards as well.  This initial investigation will help determine what
the goals of this group need to be.  The group will also work with
appropriate working groups to define required NAS standards that fall
into the areas of these other groups.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 94 Jun 94  <draft-ietf-nasreq-radius-01.txt>
                Remote Authentication Dial In User Service (RADIUS)


Privacy-Enhanced Electronic Mail (pem)
--------------------------------------

 Charter

 Current status: active working group

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

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

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

Description of Working Group:

PEM is the outgrowth of work by the Privacy and Security
Research Group (PSRG) of the IRTF.  At the heart of PEM is a set of
procedures for transforming RFC 822 messages in such a fashion as to
provide integrity, data origin authenticity, and, optionally,
confidentiality.  PEM may be employed with either symmetric or
asymmetric cryptographic key distribution mechanisms.  Because the
asymmetric (public-key) mechanisms are better suited to the large
scale, heterogeneously administered environment characteristic of the
Internet, to date only those mechanisms have been standardized.  The
standard form adopted by PEM is largely a profile of the CCITT X.509
(Directory Authentication Framework) recommendation.

PEM is defined by a series of documents.  The first in the
series defines the message processing procedures.  The second defines
the public-key certification system adopted for use with PEM.
The third provides definitions and identifiers for various
algorithms used by PEM.  The fourth defines message formats and conventions for
user registration, Certificate Revocation List (CRL) distribution,
etc.  (The first three of these were previously issued as RFCs 1113,
1114 and 1115.  All documents have been revised and are being issued
first as Internet-Drafts.)


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 Jul 94  <draft-ietf-pem-mime-06.txt>
                PEM Security Services and MIME

 Jun 94 Jul 94  <draft-ietf-pem-sigenc-01.txt>
                Security Multiparts for MIME:  Multipart/Signed and
                Multipart/Encrypted

 Aug 94 New     <draft-ietf-pem-ansix9.17-00.txt>
                Privacy Enhancement for Internet Electronic Mail:  Part V: ANSI
                X9.17-Based Key Management


Trusted Network File Systems (tnfs)
-----------------------------------

 Charter

 Current status: active working group

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

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

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

Description of Working Group:

The Trusted Network File  System Working Group is chartered to define
protocol extensions to the Network File System (NFS) Version 2 protocol
which supports network file access in a Multilevel Secure (MLS) Internet
environment.  MLS functionality includes Mandatory Access Control (MAC),
Discretionary Access Control (DAC), authentication, auditing, documentation,
and other items as identified in the Trusted Computer System Evaluation
Criteria (TCSEC) and Compartmented Mode Workstation (CMW) documents.

The primary objective of this working group is to specify extensions to the
NFS V2 protocol which support network file access between MLS systems.  It
is intended that these extensions introduce only a minimal impact on
the existing NFS V2 environment, and that unmodified NFS V2 clients and
servers continue to be fully supported.

Transferring information between MLS systems requires exchanging additional
security information along with the file data.  The general approach to be
used in extending the NFS V2 protocol is to transport additional user context
in the form of an extended NFS UNIX style credential between a Trusted NFS
(TNFS) client and server, and to map that context into the appropriate server
security policies which address file access.  In addition, file security
attributes are to be returned with each TNFS procedure call.  Otherwise,
the NFS V2 protocol remains essentially unchanged.

The Trusted System Interoperability Group (TSIG) has already developed a
specification which defines a set of MLS extensions for NFS V2, and has also
planned for the future integration of Kerberos as the authentication mechanism.
The TNFS Working Group should be able to use the TSIG Trusted NFS document
as a foundation.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 91 May 94  <draft-ietf-tnfs-spec-04.txt>
                A Specification of Trusted NFS (TNFS) Protocol Extensions


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

 Charter

 Current status: active working group

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

 Transport Area Director(s):
     Allison Mankin  <[e-mail]>

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

Description of Working Group:

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

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

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

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 92 Jul 94  <draft-ietf-avt-rtp-05.txt, .ps>
                RTP: A Transport Protocol for Real-Time Applications

 Mar 93 Sep 94  <draft-ietf-avt-video-packet-03.txt>
                Packetization of H.261 video streams


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

 Charter

 Current status: active working group

 Chair(s):
     Craig Partridge <[e-mail]>
     Scott Shenker <[e-mail]>
     John Wroclawski <[e-mail]>
     David Clark <[e-mail]>

 Transport Area Director(s):
     Allison Mankin  <[e-mail]>

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

Description of Working Group:

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

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

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

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

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

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

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

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

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

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

APPENDIX - Integrated Services Working Group Management Plan

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

The dual reasons for this management structure are:

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

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

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


 Internet-Drafts:

  No Current Internet-Drafts.


Minimal OSI Upper-Layers (thinosi)
----------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Peter Furniss <[e-mail]>

 Transport Area Director(s):
     Allison Mankin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           pluto.ulcc.ac.uk:/ulcc/thinosi/thinosi-mail-archive.txt

Description of Working Group:

The OSI upper-layer protocols (above transport) are rich in function
and specified in large, complex and numerous documents. However, in
supporting a particular application, the protocol actually used is only
a subset of the whole. An implementation is not required to support
features it never uses, and it is, or should be, possible to have
relatively lightweight implementations specialized for a particular
application or group of applications with similar requirements. The
application protocol could be an OSI application layer standard or a
protocol originally defined for TCP/IP or other environment. It will be
easier to produce such implementations if the necessary protocol is
described concisely in a single document.

An implementation, of the mapping of X Window System protocol over OSI upper-layers, is based on this principle.

The working group is chartered to produce two documents:

``Skinny bits for byte-stream'': a specification of the bit
sequences that implement the OSI upper-layer protocols (session,
presentation and ACSE) as needed to support an application that
requires simple connection, and byte-stream read and write. This will
be based on the octet sequences needed to support X. This will not be
expected to be provide a full equivalent of TCP, nor to cover specific
standardized protocols.

``Skinny bits for Directory'': a specification of the bit sequences
needed for the Directory Access Protocol - in the same style as the
byte-stream specification, but to include DAP. The level of functionality
of this is to be determined.

An important aspect of the group's work is to find out if it is possible
to produce useful and concise specifications of this kind. A  minor part
is to think of better names.

The group will also encourage the deployment of X/OSI implementations
and interworking experiments with it.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 93 Mar 94  <draft-ietf-thinosi-cookbook-03.txt>
                Octet sequences for upper-layer OSI to support basic
                communications applications


Multiparty Multimedia Session Control (mmusic)
----------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Eve Schooler <[e-mail]>
     Abel Weinrib <[e-mail]>

 Transport Area Director(s):
     Allison Mankin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.isi.edu:~/confctrl/confcrtl.mail

Description of Working Group:

The demand for Internet multimedia teleconferencing has arrived, yet an
infrastructure to support this demand is barely in place.  Multimedia
session control, defined as the management and coordination of multiple
sessions and their multiple users in multiple media (e.g., audio,
video), is one component of the infrastructure.  The Multiparty
Multimedia Session Control Working Group is chartered to design and
specify a protocol to perform these functions.

The protocol will provide negotiation for session membership,
underlying communication topology and media configuration.  In
particular, the protocol will support a user initiating a multimedia
multiparty session with other users (``calling'' other users) over the
Internet by allowing a teleconferencing application on one workstation
to explicitly rendezvous with teleconferencing applications running on
remote workstations.  Defining a standard protocol will enable
session-level interoperability between different teleconferencing
implementations.

The focus of the working group is to design a session agreement
protocol that supports tightly-controlled conferences in addition to
the loosely-controlled ones currently carried on the MBone.
Loosely-controlled sessions have little to no interaction among
members, thus limiting their ability to provide security or
coordination of session attributes (e.g., quality-of-service options
for time-critical media, floor control for media flows).  Users may
learn of loosely-controlled sessions using the ``sd'' utility or other
out of band mechanisms (e.g., e-mail, WWW).  However, there is clearly
also a need for more tightly-controlled sessions that provide
mechanisms for directly contacting other users to initiate a conference
and for negotiating conference parameters such as membership, media
encodings and encryption keys.  In addition, these sessions should
support renegotiation during a session, for example, to add or delete
members or change the media encoding.

The main goal of the working group will be to specify the session
control protocol for use within teleconferencing software over the
Internet.  The working group will focus on the aspects of the session
control problem that are well understood, while keeping an eye on
evolving research issues.  Toward this end, the working group has made
an inventory of existing conferencing systems and their session control
protocols.  The working group will document the requirements of the
existing prototypes as a basis for the protocol development.  The
working group will iteratively refine the protocol based on
implementation and operational experience.

Furthermore, the working group will coordinate with other efforts
related to multimedia conferencing, such as directory services
for cataloging users and conferences, the RTP and RTCP protocols
developed by the Audio/Video Transport Working Group, resource
reservation and management at the network level, and schemes for
multicast address allocation.


 Internet-Drafts:

  No Current Internet-Drafts.


ONC Remote Procedure Call (oncrpc)
----------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Raj Srinivasan <[e-mail]>

 Transport Area Director(s):
     Allison Mankin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           playground.sun.com: pub/oncrpc

Description of Working Group:

The purpose of the Open Network Computing Remote Procedure Call
Working Group is to update the RFCs that
describe ONC RPC to reflect the current state of the deployed and
accepted technology, and submit them for Internet standardization.

ONC RPC is currently described in ``RPC: Remote Procedure Call
Protocol Specification Version 2'' (RFC 1057), and ``XDR: External
Data Representation Standard'' (RFC 1014).

The focus of the ONC-RPC Working Group is to document and standardize
the current ONC RPC protocols. It is not the intent of this working group
to develop extensions to these protocols. However, once these tasks are
completed, discussions of future enhancements are expected. These
discussions could lead to a follow on working group.

Background:

ONC RPC is a Remote Procedure Call technology that originated in Sun
Microsystems in the early 1980s. ONC RPC was modelled on Xerox's
Courier RPC protocols. It has been widely deployed on platforms from
most major workstation vendors. It has been implemented on MS-DOS,
Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and
practically all flavors of UNIX, among others. Sun Microsystems plans
to give the ownership of ONC RPC and change control over the ONC RPC
protocols to the IETF.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 94 May 94  <draft-ietf-oncrpc-rpcv2-01.txt>
                RPC: Remote Procedure Call Protocol Specification Version 2

 Mar 94 Sep 94  <draft-ietf-oncrpc-xdr-01.txt>
                XDR: External Data Representation Standard

 May 94 New     <draft-ietf-oncrpc-auth-00.txt>
                Authentication Mechanisms for ONC RPC

 Jun 94 New     <draft-ietf-oncrpc-bind-00.txt>
                Binding Protocols for ONC RPC Version 2


Resource Reservation Setup Protocol (rsvp)
------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Robert Braden <[e-mail]>
     Lixia Zhang <[e-mail]>

 Transport Area Director(s):
     Allison Mankin  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.isi.edu:rsvp/rsvp.mail

Description of Working Group:

RSVP is a resource reservation setup protocol for the Internet. Its
major features include: (1) the use of ``soft state'' in the routers, (2)
receiver-controlled reservation requests, (3) flexible control over
sharing of reservations and forwarding of subflows, and (4) the use of
IP multicast for data distribution.

The primary purpose of this working group is to evolve the RSVP
specification and to introduce it into the Internet standards track.
The working group will also serve as a meeting place and forum for
those developing and experimenting with RSVP implementations.

The task of the RSVP working group, creating a robust specification for
real-world implementations of RSVP, will require liaison with two other
efforts: (1) continuing research and development work on RSVP in the
DARTnet research
community, and (2) the parallel IETF working group that is considering
the service model for integrated service. Although RSVP is largely
independent of the service model, its design does depend upon the
overall integrated service architecture and the requirements of
real-time applications. As an additional task, RSVP will maintain
coordination with the IPng-related working groups.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 Jul 94  <draft-ietf-rsvp-spec-03.txt, .ps>
                Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
                Specification


TCP Large Windows (tcplw)
-------------------------

 Charter

 Current status: active working group

 Chair(s):
     David Borman <[e-mail]>

 Transport Area Director(s):
     Allison Mankin  <[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:

  No Current Internet-Drafts.


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

 Charter

 Current status: active working group

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

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/ids-archive

Description of Working Group:

The Integrated Directory Services Working Group is chartered to
facilitate the integration and interoperability of current and future
directory services into a unified directory service. This work will
unite directory services based on a heterogeneous set of directory
services protocols (X.500, WHOIS++, etc.). In addition to specifying
technical requirements for the integration, the IDS Working Group will also
contribute to the administrative and maintenance issues of directory
service offerings by publishing guidelines on directory data integrity,
maintenance, security, and privacy and legal issues for users and
administrators of directories.

IDS will also assume responsibility for the completion of the
outstanding Directory Information Services Infrastructure (DISI)
Internet-Drafts, which are all specific to X.500, and for
the maintenance of ``A catalog of available X.500 implementations''
(FYI 11).

IDS will need to liase with the groups working on development and
deployment of the various directory service protocols.

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

 Internet-Drafts:

  No Current Internet-Drafts.


Integration of Internet Information Resources (iiir)
----------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Chris Weider <[e-mail]>
     Kevin Gamiel <[e-mail]>

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/iiir-archive

Description of Working Group:

The Integration of Internet Information Resources Working Group (IIIR)
is chartered to facilitate interoperability between Internet
information services, and to develop, specify, and align protocols
designed to integrate the plethora of Internet information services
(WAIS, ARCHIE, Prospero, etc.) into a single ``virtually unified
information service'' (VUIS). Such protocols would include, but are not
limited to, update protocols for distributed servers, a ``query routing
protocol'' to pass queries between existing services, protocols for
gateways between existing and future services, and standard exchange
formats (perhaps based on Z39.50) for cross-listing specific
information.

Also, where necessary, IIIR will create technical documentation for
protocols used for information services in the Internet.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 Aug 94  <draft-ietf-iiir-transponders-02.txt>
                Resource Transponders

 Mar 93 Aug 94  <draft-ietf-iiir-vision-02.txt>
                A Vision of an Integrated Internet Information Service

 Aug 93 May 94  <draft-ietf-iiir-publishing-01.txt>
                Publishing Information on the Internet with Anonymous FTP

 Aug 94 New     <draft-ietf-iiir-z3950-00.txt>
                Using the Z39.50 Information Retrieval Protocol in the Internet
                Environment


Internet School Networking (isn)
--------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Jennifer Sellers <[e-mail]>

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe isn-wg <first name> <last name>
     Archive:

Description of Working Group:

The Internet School Networking Working Group is chartered to address
issues related to the connection of primary and secondary schools
worldwide to the Internet.  The key audiences include network service
providers and educational policy makers responsible for network access
and use.  The key areas of focus for this group are advocacy and
articulation.

1.  Advocacy.  The ISN Working Group will facilitate dialog between the
primary and
secondary education community and the Internet engineering community in
order to identify and fulfill the needs of the primary and secondary school
community.

2.  Articulation.  Informed by the group's experience, and with input
from other IETF working groups, the ISN Working Group will articulate
solutions to the challenges a school may experience in seeking and gaining a
connection to the Internet, as well as the benefits of such a
connection.  Advantages to Internet connectivity may be articulated by
means of pointers to such services as user interfaces, directories,
organizations, and training programs, as well as to other resources.
Articulation will most often be in the form of periodic documents
that address key issues of interest to the school networking
community.  Representative issues to be addressed by the group include
connectivity models, educational directories, and acceptable use
policies.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 94 Jul 94  <draft-ietf-isn-k12-guide-01.txt, .ps>
                K-12 Internetworking Guidelines

 Apr 94 Apr 94  <draft-ietf-isn-aup-01.txt>
                Acceptable Use Policy Definition


Network Information Services Infrastructure (nisi)
--------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     April Marine <[e-mail]>

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

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

Description of Working Group:

The NISI Working Group will explore the requirements for common, shared
Internet-wide network information services. The goal is to develop an
understanding for what is required to implement an information services
``infrastructure'' for the Internet.  The work will begin with existing
NIC functions and services and should build upon work already being
done within the Internet community. A primary goal of the group is to
facilitate the development of relationships between NICs that will
result in the presentation of a seamless user support service.  NISI
will work with all NICs, including the InterNIC, to achieve the goal of
a fully-functioning, cooperative mesh of worldwide NICs.  In addition
to creating policies for interaction, NISI will address areas such as
common information formats, methods of access, user interface, and
issues relating to security and privacy of Internet databases.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 94 New     <draft-ietf-nisi-nicdoc-00.txt>
                Network Information Center Guidelines


Network Training Materials (trainmat)
-------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Jill Foster <[e-mail]>
     Mark Prior <[e-mail]>

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.near.net:/mail-archives/us-wg*

Description of Working Group:

Widespread familiarity with global network services and competence in
using them brings benefit to individual users, enriches the information
skills and resources of the community and optimizes the return in
investment in networked services.

The Network Training Materials Working Group is chartered to enable the
research community to make better use of the networked services.
Towards this end, the working group will work to provide a mix of
training materials for the broad academic community which will:
(1) enable user support staff to train users to use the networked services,
and (2) provide users with self-paced learning material.  In the first
instance, it will not deal with operational training.

This working group is the IETF component of a joint RARE/IETF group
working on network training materials.

The working group will create a catalogue of existing network training
materials (using the IAFA style Data Elements where appropriate),
identify the gaps in network training materials and work to identify
the problems associated with hands on training workshops using
networked services providing a real service.


 Internet-Drafts:

  No Current Internet-Drafts.


Uniform Resource Identifiers (uri)
----------------------------------

 Charter

 Current status: active working group

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

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           archives.cc.mcgill.ca:~/pub/mailing-lists/uri-archive

Description of Working Group:

The Uniform Resource Identifiers Working Group is chartered to
define a set of standards for the encoding of system-independent
resource location and identification information for the use of
Internet information services.

This working group is expected to produce a set of documents that
specify standard representations of Uniform Resource Locators
(URLs) for encoding location and
access information across multiple information systems, Unique Resource
Serial Numbers (URSNs) which specify a standardized method for encoding
unique resource identification information for Internet resources, and
Uniform Resource Identifiers (URIs) which specify a standardized
method for encoding combined resource identification and location
information systems to be used for resource discovery and access
systems in an Internet environment.  Such standards
are expected to build upon the document discussed at the UDI BOF
session held during the 24th IETF meeting in Boston

Such a set of standards will provide a framework that allows the
Internet user to specify the location and access information for files
and other resources on the Internet, users and network-based
tools to uniquely identify specific resources on the Internet, and
the creation and operation of resource discovery and access
systems for the Internet.  The security of such resource discovery
services will also be considered to be an integral part of the work
of this group.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 93 Sep 94  <draft-ietf-uri-url-07.txt>
                Uniform Resource Locators (URL)

 May 93 Aug 94  <draft-ietf-uri-resource-names-02.txt>
                Uniform Resource Names

 Mar 94 New     <draft-ietf-uri-urn-req-00.txt>
                Requirements for Uniform Resource Names

 Apr 94 New     <draft-ietf-uri-urc-00.txt>
                Specification of Uniform Resource Characteristics

 Apr 94 New     <draft-ietf-uri-urn2urc-00.txt>
                URN to URC resolution scenario

 Jun 94 Aug 94  <draft-ietf-uri-irl-fun-req-01.txt>
                Functional Requirements for Internet Resource Locators

 Jul 94 New     <draft-ietf-uri-urc-spec-00.txt>
                Encoding and Use of Uniform Resource Characteristics

 Aug 94 New     <draft-ietf-uri-relative-url-00.txt>
                Relative Uniform Resource Locators


User Services (uswg)
--------------------

 Charter

 Current status: active working group

 Chair(s):
     Joyce K. Reynolds <[e-mail]>

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.near.net:/mail-archives/us-wg*

Description of Working Group:

The User Services Working Group provides a regular forum for people
interested in user services to identify and initiate projects designed
to improve the quality of information available to end-users of the
Internet.  (Note that the actual projects themselves will be handled
by separate groups, such as IETF working groups created to perform certain
projects, or outside organizations such as SIGUCCS.)

(1) Meet on a regular basis to consider projects designed to improve services
    to end-users.  In general, projects should:

       - Clearly address user assistance needs;

       - Produce an end-result (e.g., a document, a program plan, etc.);

       - Have a reasonably clear approach to achieving the end-result
         (with an estimated time for completion); and

       - Not duplicate existing or previous efforts.

(2) Create working groups or other focus groups to carry out projects deemed
    worthy of pursuing.

(3) Provide a forum in which user services providers can discuss and identify
    common concerns.

 Internet-Drafts:

  No Current Internet-Drafts.


Whois and Network Information Lookup Service (wnils)
----------------------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     Joan Gargano <[e-mail]>

 User Services Area Director(s):
     Joyce Reynolds  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ucdavis.edu:~/archive/wnils

Description of Working Group:

The Network Information Center maintains the central ``NICNAME''
database and server, defined in RFC 954, providing on-line look-up of
individuals, network organizations, key nodes, and other information
of interest to those who use the Internet.  Other distributed
directory information servers and information retrieval tools have
been developed and it is anticipated more will be created.  Many sites
now maintain local directory servers with information about
individuals, departments and services at that specific site.
Typically these directory servers are network accessible.  Because
these servers are local, there are now wide variations in the type of
data stored, access methods, search schemes, and user interfaces.  The
purpose of the Whois and Network Information Lookup Service (WNILS)
Working Group is to expand and define the standard for WHOIS services,
to resolve issues associated with the variations in access and to
promote a consistent and predictable service across the network.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 Aug 94  <draft-ietf-wnils-whois-03.txt>
                Architecture of the Whois++ Index Service

 Jul 93 Jul 94  <draft-ietf-wnils-whois-lookup-01.txt>
                Whois and Network Information Lookup Service Whois++

 Apr 94 Aug 94  <draft-ietf-wnils-whois-arch-01.txt>
                Architecture of the WHOIS++ service

 Aug 94 New     <draft-ietf-wnils-whois-mesh-00.txt>
                How to interact with a Whois++ mesh