Access/Synchronization of the Internet Directories (asid)
---------------------------------------------------------
Charter
Current status: active working group
Chair(s):
Tim Howes <tim@umich.edu>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
Erik Huizer <Erik.Huizer@SURFnet.nl>
Mailing lists:
General Discussion:ietf-asid@umich.edu
To Subscribe: ietf-asid-request@umich.edu
Archive: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive
Description of Working Group:
There is a clear need to provide and deploy a well managed Directory
Service for the Internet. A so-called White Pages Directory Service
providing people- and organizational- information, is especially long
overdue. While the ultimate goal is a general Directory Service for
the Internet, this is too ambitious a goal to be tackled by a single
working group. Therefore ASID will keep a tight focus on access and
synchronization protocols for an Internet White Pages Directory Service.
Other related working groups will be formed in the Applications Area
that will deal with other aspects of the Internet Directory Service.
Currently there are various protocols under development in the Internet
that aim to provide such a service: Internet X.500, WHOIS++, NETFIND,
CSO, RWHOIS, etc. To allow these services to evolve to a ubiquitous
Internet Directory Service, a hybrid system that allows interaction
between the various different services is a requirement.
The ASID Working Group will define, evolve, and standardize protocols,
algorithms and access methods for a White Pages Directory Service on the
Internet.
The following protocols (some still under development, some completed by
other IETF working groups) will be considered by the working group:
- Lightweight Directory Acces Protocols (LDAP and Connectionless LDAP)
- User Friendly Naming (UFN) and User Friendly Searching (UFS)
- The SOLO directory access and searching system
- The WHOIS++ directory service
The following work items are handled by other groups, and as such are
outside the scope of this group. However their results are important to
the development of a White Pages Directory Service, and will be taken
into account:
- The Hypertext Transfer Protocol (HTTP)
- The UR* definitions
- The NETFIND directory service
The group will focus on harmonizing, evolving and developing protocols
and algorithms that deal with access to and synchronization of
Directory Service, both ad hoc and standards-based, with a goal of
converging where possible towards a hybrid system that ties together
various forms of Directory Service. Clearly, protocol-level
integration is only part of the solution. But to keep this group
tightly focused, harmonizing directory information and service models
will be tackled by other working groups.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 94 New <draft-ietf-asid-schema-00.txt>
Schema Publishing in X.500 Directory
Nov 94 New <draft-ietf-asid-x500-url-00.txt>
Definition of an X.500 Attribute Type and Object Class to Hold
Uniform Resource Locators (URLs)
Nov 94 New <draft-ietf-asid-user-friendly-dir-00.txt, .ps>
Using the OSI Directory to achieve User Friendly Naming
Nov 94 New <draft-ietf-asid-dist-names-00.txt, .ps>
A String Representation of Distinguished Names
Nov 94 New <draft-ietf-asid-lightdirect-00.txt>
Lightweight Directory Access Protocol
Nov 94 New <draft-ietf-asid-syntaxes-00.txt>
The String Representation of Standard Attribute Syntaxes
Electronic Data Interchange (edi)
---------------------------------
Charter
Current status: active working group
Chair(s):
Dave Crocker <dcrocker@mordor.stanford.edu>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
John Klensin <Klensin@mail1.reston.mci.net>
Mailing lists:
General Discussion:ietf-edi@byu.edu
To Subscribe: listserv@byu.edu
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.
HyperText Markup Language (html)
--------------------------------
Charter
Current status: active working group
Chair(s):
Tim Berners-Lee <timbl@w3.org>
Eric Sink <esink@spyglass.com>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
Erik Huizer <Erik.Huizer@SURFnet.nl>
Mailing lists:
General Discussion:html-wg@oclc.org
To Subscribe: html-wg-request@oclc.org
In Body: subscribe html-wg <your name>
Archive: http://www.ics.uci.edu/pub/ietf/html/
Description of Working Group:
Note on Mailing Lists
General discussion about HTML is normally carried out on the 'www-html'
list, which should be used for anything which is not the work of this
group.
Address: www-html@info.cern.ch
To subscribe: listserv@info.cern.ch
In body: SUBSCRIBE WWW-HTML your full name
Archive: http://gummo.stanford.edu/html/hypermail/www-html-1994q2.index.html
Description
The HTML Working Group is chartered firstly to describe, and secondly to
develop, the HyperText Markup Language (HTML). The group's work is to be
based on existing practice on the Internet, and will make due reference
to the SGML standard.
The group will build upon a working specification originally written by
Tim Berners-Lee, much work done by Dan Connolly in editing and testing,
the recent editing of Karen Muldrow, and the HTMLPlus specification
edited by Dave Raggett. The working group takes over the work of the
informal HTML Implementors Group which met at the WWW94 conference in
Geneva, the HTML workshop at that conference, and an informal meeting and
an IETF BOF in Toronto in July 94.
The HTML standard will provide a format for hypertext files of wide
applicability, and particularly as a mandatory common format for all
WorldWide Web applications.
The standard will specify the relationships between HTML and other
standards and practices such as URIs, HTTP, MIME and SGML.
Focus
The working group will have a strong focus to:
o Describe existing features before developing new features
o Base specification on existing practice
o Express the relationship of HTML to URIs, MIME, SGML, HyTime and
HTTP
o Define conformance levels
o Define transition possibilities and compatibilities between
versions and levels
The working group will work in two stages.
Descriptive specification
The first priority will be to complete the specfication of existing
practice on the Internet, defining it in terms which make development
of new features as straightforward as possible. This specification
will cover HTML up to that which has been called level 2 (i.e.,
including basic features, highlighting, images and forms). During this
period discussion of new features should not be carried out on the
working group mailing list.
Development
Once the descriptive specification is submitted to the standards
process, the group will work on development of HTML, taking on the work
known as HTMLPlus. This work will include formats for tables, figures
and mathematical formulae.
In the absence of other proposals, the working group will terminate
having produced its milestones and the RFCs having achieved standards
status.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Nov 94 New <draft-ietf-html-fileupload-00.txt>
File Transfer from World-Wide Web Browsers to Servers
Nov 94 New <draft-ietf-html-spec-00.txt>
HyperText Markup Language Specification - 2.0
Internet Message Access Protocol (imap)
---------------------------------------
Charter
Current status: active working group
Chair(s):
Terry Gray <gray@cac.washington.edu>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Mailing lists:
General Discussion:imap@cac.washington.edu
To Subscribe: imap-request@cac.washington.edu
Archive: ftp.cac.washington.edu:~/imap/imap_archive
Description of Working Group:
The Interactive Mail Access Protocol (IMAP) Working Group
is chartered to refine and extend the current IMAP2 protocol as a
candidate standard for a client-server Internet e-mail protocol to
manipulate remote mailboxes as if they were local. An explicit
objective is to retain compatibility with the growing installed base
of IMAP2-compliant software. It is expected that the resulting
specification will replace both RFC 1176 and the more recent (as yet
unplublished) IMAP2bis extensions document.
The IMAP Working Group will also investigate how to provide for
``disconnected operation'' capabilities similar to the DMSP protocol
(RFC 1056, with Informational status) with a goal of making it
possible for IMAP to replace DMSP.
An e-mail access protocol provides a uniform, operating
system-independent way of manipulating message data (e-mail or
bulletin board) on a remote message store (repository). Mail user
agents implementing such a protocol can provide individuals with a
consistent view of the message store, regardless of what type of
computer they are using, and regardless of where they are connected
in the network. Multiple concurrent sessions accessing a single
remote mailbox, and single sessions accessing multiple remote
mailboxes, are both possible with this approach.
This differs from POP3 (RFC 1225) in that POP is a store-and-forward
transport protocol that allows an MUA to retrieve pending mail from
a mail drop (where it is then usually deleted automatically),
whereas IMAP is focused on remote mailbox manipulation rather than
transport. IMAP differs from various vendor-specific remote access
approaches in that IMAP is an open protocol designed to scale well
and accommodate diverse types of client operating systems.
Security-related tasks include how to incorporate secure
authentication mechanisms when establishing a session, and possible
interactions with Privacy Enhanced Mail.
It is expected that most of the work of this group will be conducted
via e-mail. A goal is to integrate and update RFC 1176 and the
existing IMAP2bis draft, then submit the result as an Internet-Draft
well before the November 1993 IETF meeting, which would then focus on
detailed review of the text in preparation for submission as a
Proposed Standard before the end of 1993.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Feb 94 Nov 94 <draft-ietf-imap-imap4-07.txt>
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
Jun 94 Nov 94 <draft-ietf-imap-auth-02.txt>
IMAP4 Authentication mechanisms
Jun 94 New <draft-ietf-imap-compat-00.txt>
IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
Jun 94 Nov 94 <draft-ietf-imap-disc-01.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 <genovese@es.net>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
Erik Huizer <Erik.Huizer@SURFnet.nl>
Mailing lists:
General Discussion:wps@SURFnet.nl
To Subscribe: wps-request@SURFnet.nl
Archive: ftp.es.net:/pub/ietf/wps
Description of Working Group:
At the Seattle IETF in March 1994, a BOF was held on the establishment
of a Simple Internet White Pages Service (SIWPS). A basic model was
proposed, and further work was defined. One of the requested work items
was a definition of the basic requirements for such a service. This
working group is chartered to produce a single Informational RFC
capturing these basic requirements. It will do so without prejudice to
existing solutions or implementations.
The requirements document should only contain the basic requirements
for a SIWPS. The list is not meant to be exhaustive, but rather should
provide a set of minimum requirements to guide the overall structure of
white pages service effort; these requirements can be used by related
IETF working groups to start to define the Internet white pages service.
The working group is meant to be short-lived and to produce only the
one document.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Jul 94 Nov 94 <draft-ietf-whip-iwps-requirements-01.txt>
A Specification for the Simple Internet White Pages Service
MHS-DS (mhsds)
--------------
Charter
Current status: active working group
Chair(s):
Kevin Jordan <Kevin.Jordan@cdc.com>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Mailing lists:
General Discussion:mhs-ds@mercury.udev.cdc.com
To Subscribe: mhs-ds-request@mercury.udev.cdc.com
Archive: mercury.udev.cdc.com:~/pub/archives/mhs-ds-archive
Description of Working Group:
The MHS-DS Working Group works on issues relating to Message Handling
Services use of Directory Services. The message handling services are
primarily X.400, but issues relating to RFC 822 use of Directory and
Directory support for RFC 822 and X.400 interworking are in the scope of
the group. Directory and Directory Services refer to the services
based upon the CCITT X.500 recommendations and additional ISO
standards, stable implementation agreements, and RFCs, as specified by
the OSI-DS Working Group. The major aims of the MHS-DS Working Group
are:
1. Define a set of specifications to enable effective, large-scale
deployment of X.400.
2. Study issues associated with supporting X.400 communities which lack
access to X.500 Directory, and define requirements for tools which: (a)
extract information from the X.500 Directory for use by non-X.500
applications, and (b) upload information into the X.500 Directory.
3. Coordinate a pilot project which deploys MHS information into the
X.500 Directory and uses it to facilitate mail routing and address
mapping. The results of this pilot will be documented, and experience
gained from the project will be fed back into the Internet
specifications created by the working group.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
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 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 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 <cargille@cs.wisc.edu>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
John Klensin <Klensin@mail1.reston.mci.net>
Mailing lists:
General Discussion:mailext@cs.wisc.edu
To Subscribe: listserv@cs.wisc.edu
In Body: subscribe mailext Your Full Name
Archive:
Description of Working Group:
The Mail Extensions Working Group will review, refine as
needed, and then make a recommendation on standardization of several
recent proposals for standards-track compatible extensions to SMTP
(via the Service Extensions mechanism), MIME (via new Content
Subtypes), and MIME-MHS (via MIME Content Subtypes and usage rules).
It will also act as the review body for several documents that
clarify and provide applicability statements about the use of
Internet mail: that work will ultimately lead to an update for the
mail-related section of RFC 1123. Part of that effort involves
RARE WG-MSG documents that address the Internet's installed
electronic mail infrastructure. Since such documents should not
be processed in RARE alone, this working group will act as the
IETF focus for reviewing them.
Initial drafts of all of the documents that the working group is
expected to review have already been, or will soon be, published.
The working group will be starting with documents that have been
prepared as individual (or spontaneous design team) contributions.
It is not expected to initiate new work. On the other hand, it is
expected to make explicit "not ready for standardization" or
"inappropriate for standardization" recommendations if that is
appropriate.
The working group will be initialized with the following Internet-
Drafts or their successors, listed alphabetically. A major purpose
of its first meeting is to prune or add to this list.
draft-freed-ftbp-00.txt
draft-freed-smtp-pipeline-00.txt
draft-houttuin-mailservers-02.txt
draft-rare-msg-a-bombs-00.txt
draft-rare-msg-c-bombs-00.txt
draft-vaudreuil-smtp-binary-04.txt
draft-vaudreuil-smtp-stream-00.txt
Internet-Drafts:
Posted Revised I-D Title <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 <Harald.T.Alvestrand@uninett.no>
Ned Freed <ned@innosoft.com>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
John Klensin <Klensin@mail1.reston.mci.net>
Mailing lists:
General Discussion:notifications@cs.utk.edu
To Subscribe: notifications-request@cs.utk.edu
Archive:
Description of Working Group:
The purpose of the NOTARY Working Group is to give the Internet e-mail
user better tools to build a system where the sender of a message can
find out what happened to it.
Work items for this group:
- Specify a reporting format that can be used for delivery,
non-delivery and receipt reports. The format should conform to MIME,
and be at least as informative as current examples of non-standardized
non-delivery notifications. This format should be usable as-is in
current e-mail products to replace the current, non-standardized and
sometimes quite cryptic textual non-delivery reports. The drafts by
Keith Moore and Greg Vaudreuil are taken as a working basis. (See
the document list below for details.)
- Specify a way for the sender to request that positive delivery
reports be generated for a message sent via SMTP. The draft by
Keith Moore is taken as a working basis.
- Generate an Informational document that gives advice on how to handle
delivery notifications (positive and negative) and requests for them at
boundaries to other mail systems, such as X.400 and PC LANs.
Relationship to X.400 and X.400 gateways:
While the intent of this work includes specification of an
acknowledgement system that can be translated to work across the
821/822/MIME to X.400 boundary, the effort will focus on design from
the former standpoint. That will be followed by changes to the
successor of RFC 1327 to match these features, but those changes will be
made as part of the RFC 1327 revision process, not by this working group.
Of course, if any features specified by this working group turn out to be
impossible to accomodate in the RFC 1327 revision, that would be cause for
reviewing both sets of specifications.
Additional items not on the agenda of this working group:
- Specification of a way in which the sender can request that a receipt
notification (``the recipient has read this message'') be sent upon
receipt of the message. The document should identify the controversial
aspects of such a function, and should attempt to specify the function
in a way that minimizes surprise at both the sending and receiving end,
even in the face of varying local policies.
However, the group will, as part of its work, make a recommendation to
the IESG where and how such work should be tackled.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Sep 93 Nov 94 <draft-ietf-notary-smtp-drpt-02.txt>
SMTP Service Extension for Delivery Status Notifications
Sep 93 Nov 94 <draft-ietf-notary-mime-delivery-03.txt>
An Extensible Message Format for Delivery Status Notifications
Aug 94 New <draft-ietf-notary-mime-report-00.txt>
Multipart/Report
Quality Information Services (quis)
-----------------------------------
Charter
Current status: active working group
Chair(s):
Mitra <mitra@path.net>
April Marine <amarine@atlas.arc.nasa.gov>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
Erik Huizer <Erik.Huizer@SURFnet.nl>
Mailing lists:
General Discussion:quality@naic.nasa.gov
To Subscribe: listmanager@naic.nasa.gov
In Body: subscribe quality
Archive: listmanager@naic.nasa.gov body='index quality'
Description of Working Group:
The number of information services (Gopher, WWW, etc.) on the Internet is
growing rapidly. This poses a problem for administrators, implementors
and providers in maintaining the quality of the information service (as
opposed to quality of the information itself).
The aim of this working group is to deal with one of the specific
problems with respect to quality of the information service, namely link
problems. A link problem is defined as the case where a user selects a
link and is returned slow data, no data, incomplete data or wrong data.
The working group will analyze link failures and their causes, and, based
on the analysis, it will devise both technical solutions and operational
recommendations to address this specific problem.
Internet-Drafts:
No Current Internet-Drafts.
TFTP Extensions (tftpexts)
--------------------------
Charter
Current status: active working group
Chair(s):
Art Harkin <ash@cup.hp.com>
Gary Malkin <gmalkin@xylogics.com>
Applications Area Director(s):
John Klensin <Klensin@mail1.reston.mci.net>
Erik Huizer <Erik.Huizer@SURFnet.nl>
Area Advisor
John Klensin <Klensin@mail1.reston.mci.net>
Mailing lists:
General Discussion:tftpexts@hpindsh.cup.hp.com
To Subscribe: tftpexts-request@hpindsh.cup.hp.com
Archive: onet2.cup.hp.com:pub/dist/tftpexts/tftpexts_archive
Description of Working Group:
The TFTP Extensions Working Group will review, refine as needed, and
then make a recommendation on standardization of several recent
standards-track proposals to extend TFTP. These proposals include a
backward compatible extension mechanism for TFTP and related extension
options for this mechanism.
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 appropriate.
The working group will be begin with the following Internet-Drafts or
their successors:
- draft-malkin-tftp-option-ext-00.txt
- draft-malkin-tftp-blksize-opt-00.txt
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Sep 94 Oct 94 <draft-ietf-tftpexts-option-ext-01.txt>
TFTP Option Extension
Sep 94 Oct 94 <draft-ietf-tftpexts-blksize-opt-01.txt>
TFTP Blocksize Option
Address Lifetime Expectations (ale)
-----------------------------------
Charter
Current status: active working group
Chair(s):
Frank Solensky <solensky@ftp.com>
Tony Li <tli@cisco.com>
IP: Next Generation Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:ipv4-ale@ftp.com
To Subscribe: ipv4-ale-request@ftp.com
Archive: research.ftp.com:pub/ale/
Description of Working Group:
The primary purpose of the Address Lifetime Expectations Working Group
is to develop an estimate for the remaining lifetime of the IPv4
address space based on currently known and available technologies. The
members of the working group will consider whether more stringent
address allocation and utilization policies might provide additional
time and, if so, recommend such policies. The working group will also
investigate whether it is worthwhile to mount a serious effort to
reclaim addresses and/or to renumber significant portions of the
Internet. It will also weigh the benefit of other potential options
against their expected cost and notify the responsible working groups
or area directors of those proposals the ALE group considers worthy of
further attention.
The working group will have several ongoing activities which will
result in reports to the IETF community and the IPng Area Directors.
One ongoing activity is to produce monthly predictions of the address
space exhaustion timeframe, assessing the accuracy of these predictions
and the data on which they are based. The group will also project the
impact of various policy compliance data and possible policy
recommendations.
Another ongoing activity is to monitor the perceived utilization of
address space and identify sources of poor utilization, set address
utilization goals and to itemize possible policies to improve
utilization.
The group will also monitor the number of routes present in the
Internet backbones, and identify sources of poor aggregation within the
network, (in conjunction with the BGP Deployment Working Group), and make
necessary recommendations to insure continued operations.
Internet-Drafts:
No Current Internet-Drafts.
IPNG (ipngwg)
-------------
Charter
Current status: active working group
Chair(s):
Ross Callon <callon@wellfleet.com>
Steve Deering <deering@parc.xerox.com>
IP: Next Generation Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe ipng
Archive: parcftp.xerox.com:/pub/ipng
Description of Working Group:
Editor: Bob Hinden (hinden@eng.sun.com)
The next generation of the Internet Protocol (IPv6) is intended to support
Internet traffic for many years into the future by providing enhancements
over the capabilities of the existing IPv4 service. This working group
will produce specifications for the core functionality of that service.
The working group shall carry out the recommendations of the IPng Area
Directors as outlined at the July 1994 IETF and in "The Recommendation for
the IP Next Generation Protocol", Internet-Draft,
(draft-ipng-recommendation-00.txt), September 1994.
The working group shall use the following documents as the basis of its
work:
Simple Internet Protocol Plus (SIPP) Specfication (128 bit version)
SIPP Addressing Architecture
An Architecture for IPv6 Unicast Address Allocation
Simple SIPP Transition (SST) Overview
SIPP Program Interfaces for BSD Systems
SIPP Security Architecture
SIPP Authentication Header
SDRP Routing Header for SIPP-16
IP Next Generation Overview
ICMP and IGMP extensions for SIPP
FTP Operation Over Big Address Records (FOOBAR)
DNS Extensions to support SIPP
Enhancements to be considered:
Large Packets: Consider extensions for support of datagrams which are
larger than 64K.
Source Routing: The working group shall consider enhanced source routing
capabilities for IPng.
Tunneling: Complete specification of IPng in IPng tunneling.
Address format and assignment plan: The working group shall review the
details of address structure as specified in [SIPP-16] and shall repair
any deficiencies with respect to current or near-term addressing
requirements, assuming a fixed, 16-byte size. The specification shall
provide a mechanism for supporting multiple additional formats, for
possible enhancement to incorporate other popular addressing schemes.
Routing Structure: In completing the addressing details, the working
group shall ensure that routing according to current, CIDR-like schemes
can be supported comfortably.
Autoconfiguration: Coordinate with the IPng Address Autoconfiguration
Working Group.
Transition: The working group shall coordinate with the related
transition and conversion efforts (ngtrans, tacit, nosi, etc.) to ensure
that the base specification provides the facilities required for the
transition from IPv4.
Security: A set of base documents for IPng security shall be completed.
This shall include algorithms for authentication and privacy carried as
IPng extension headers and include an initial selection of required
encryption and key management algorithms and a facility to support other
optional algorithms. The working group should also examine IPng
firewall issues and if necessary develop specific firewall frameworks.
Minimum MTU: Consider a larger minimum MTU.
Header Compression: Consider ways to abbreviate the IPng header in the
contexts of native IPng, multiple IPng packets in a flow, and
encapsulated IPng.
TCP/UDP: The IPng Working Group will specify the procedures for hosts to
compute and verify TCP/UDP pseudo-headers. Any other changes to TCP
beyond making TCP work with IPng are out of scope of the working group
and should be dealt with by a TCPng Working Group.
The IPng Working Group will coordinate with other groups, including Mobile
IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR, Security,
Applications, Network Management, IP over ATM, etc.
Internet-Drafts:
No Current Internet-Drafts.
Common Architecture for Next Generation IP (catnip)
---------------------------------------------------
Charter
Current status: active working group
Chair(s):
Vladimir Sukonnik <sukonnik@process.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:catnip@world.std.com
To Subscribe: catnip-request@world.std.com
Archive: world.std.com:~/pub/catnip/*
Description of Working Group:
CATNIP is a new version of the IP protocol, converged with a
compressed form of CLNP, and a form of Novell IPX that permits
general interoperation. The objective is to provide common ground
between the Internet, OSI, and the Novell protocols, as well as to
advance the Internet technology to the scale and performance of the
next generation of internetwork technology. CATNIP has been assigned
the IP version number 7. The CATNIP proposal has evolved from the
TP/IX protocol (RFC 1475) and the TUBA proposal (RFC 1347).
The working group is chartered to review the CATNIP protocol,
evaluate issues arising during product development and deployment
planning, and to document problems and explanations for any parts of
the coexistance with IPv4 not covered directly in the CATNIP-IPv4
interoperation design.
CATNIP includes definitions covering the same ground as the TUBA
project, and within the charter of the TUBA Working Group. This will
be handled by coordination with the TUBA Working Group. The intent is
to arrive at complete alignment between the TUBA work and the CLNP
component in CATNIP.
The group will also continue to be the forum for development of the RAP
protocol and the TCP extensions while in experimental status; this
work will need to be moved to the Transport and Routing Area(s) if it
is to be advanced; this work is outside the charter of the IPng Area.
Internet-Drafts:
No Current Internet-Drafts.
DNS IXFR, Notification, and Dynamic Update (dnsind)
---------------------------------------------------
Charter
Current status: active working group
Chair(s):
Randy Bush <randy@psg.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:namedroppers@internic.net
To Subscribe: namedroppers-request@internic.net
Archive: ftp.merit.edu:/internet/documents/ietf/dns
Description of Working Group:
The DNS Incremental Transfer, Notify, and Dynamic Update Working Group
is concerned with three areas of future DNS protocol development:
Incremental Zone Transfer - As the sizes of some zone files have grown
quite large, it is believed that a protocol addition to allow the
transfer of only the changed subset of a zone will reduce net traffic
and the load on critical servers.
Change Notification - There can be large time intervals during which
at least one secondary has data that is inconsistent with the primary.
The proposed ``notify'' mechanism (where the primary sends a message
to known secondaries) facilitates fast convergence of servers
vis-a-vis consistency of data in the zones.
Dynamic Update - The need to frequently update small portions of a
large zone and to have those updates propagate is perceived.
Internet-Drafts:
Posted Revised I-D Title <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
Nov 94 New <draft-ietf-dnsind-ixfr-00.txt>
Incremental Transfer in DNS
Dynamic Host Configuration (dhc)
--------------------------------
Charter
Current status: active working group
Chair(s):
Ralph Droms <droms@bucknell.edu>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:host-conf@sol.bucknell.edu
To Subscribe: host-conf-request@sol.bucknell.edu
Archive: sol.bucknell.edu:/dhcwg
Description of Working Group:
The purpose of this working group is to investigate network
configuration and reconfiguration management, and determine those
configuration functions that can be automated, such as Internet
address assignment, gateway discovery and resource location, and those
which cannot be automated (i.e., those that must be managed by network
administrators).
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Nov 94 New <draft-ietf-dhc-dhcp-00.txt>
Dynamic Host Configuration Protocol
IP Over AppleTalk (appleip)
---------------------------
Charter
Current status: active working group
Chair(s):
John Veizades <veizades@wco.ftp.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:apple-ip@apple.com
To Subscribe: apple-ip-request@apple.com
Archive:
Description of Working Group:
The IP Over AppleTalk Working Group is chartered to facilitate the connection
of Apple Macintoshes to IP internets, and to address the issues of
distributing AppleTalk services in an IP internet.
Internet-Drafts:
Posted Revised I-D Title <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 <laubach@com21.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:ip-atm@hpl.hp.com
To Subscribe: ip-atm-request@hpl.hp.com
Archive: Send message to ip-atm-request@hpl.hp.com
Description of Working Group:
The IP Over Asynchronous Transfer Mode Working Group will focus on
the issues involved in running internetworking protocols over
Asynchronous Transfer Mode (ATM) networks. The final goal for the
working group is to produce standards for the TCP/IP protocol suite,
and recommendations which could be used by other internetworking
protocol standards (e.g., ISO, CLNP and IEEE 802.2 Bridging).
The working group will initially develop experimental protocols for
encapsulation, multicasting, addressing, address resolution, call set
up, and network management to allow the operation of internetwork
protocols over an ATM network. The working group may later submit
these protocols for standardization.
The working group will not develop physical layer standards for ATM.
These are well covered in other standards groups and do not need to be
addressed in this group.
The working group will develop models of ATM internetworking
architectures. This will be used to guide the development of specific IP
over ATM protocols.
The working group will also develop and maintain a list of technical
unknowns that relate to internetworking over ATM. These will be used
to direct future work of the working group or be submitted to other
standards or research groups as appropriate.
The working group will coordinate its work with other relevant
standards bodies (e.g., ANSI T1S1.5) to insure that it does not
duplicate their work, and that its work meshes well with other
activities in this area. The working group will select among ATM
protocol options (e.g., selection of an adaptation layer) and
make recommendations to the ATM standards bodies regarding the
requirements for internetworking over ATM where the current ATM
standards do not meet the needs of internetworking.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Apr 94 Nov 94 <draft-ietf-ipatm-sig-02.txt>
ATM Signaling Support for IP over ATM
Internet Stream Protocol V2 (st2)
---------------------------------
Charter
Current status: active working group
Chair(s):
Lou Berger <lberger@bbn.com>
Luca Delgrossi <luca@ibmpa.awdpa.ibm.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:st@ibminet.awdpa.ibm.com
To Subscribe: st-request@ibminet.awdpa.ibm.com
Archive: ibminet.awdpa.ibm.com:~/pub/st/st-archive
Description of Working Group:
The Internet Stream Protocol V2 Working Group was formed to clarify and refine
the existing specification of the Stream Protocol, Version 2 (ST-II)
contained in RFC 1190. Since ST-II is a protocol that is already used in
audio-visual and reserved-resource applications and services, the focus
of this group is near-term, and its primary purpose is to provide a
specification that corrects errors in the existing ST-II specification and
makes it easier to implement ST-II in a manner that is likely to be
interoperable with other ST-II implementations.
The group intends to address several areas of the ST-II
specification, including:
a) the formal definition of states and state transitions;
b) the removal of mechanisms which are too complicated as currently
designed and which have not shown any use in practice;
c) address the ambiguities caused by the current implementation
subsets;
d) definition of a clear IP encapsulation mechanism;
e) minor revisions suggested by experience with ST-II.
These modifications are expected to reduce implementation time and to
improve the utility and interoperability of existing and future ST-II
implementations. The working group may also provide guidance on the
use of standard routing protocols to support ST-II, and on the format and
use of flow specifications. Finally, particular attention will be
given to the specification of groups of streams as required for the
efficient sharing of resources. Input from current ST-II developers and
application developers will be solicited to help clarify issues that
the working group should address.
It is the goal of the group to produce a refined ST-II
specification that can be used to rapidly satisfy operational
requirements. The result of this group is expected to be an
Experimental RFC. It is not the intention of this working group to
define a new communication or resource reservation protocol. ST-II is
part of the ongoing IETF efforts to develop protocols that address
resource reservation issues. It is possible that future IETF working
groups will produce other operational protocol options in this area.
Related work by other IETF working groups shall be carefully monitored
to see if the actions of this Working Group should be revised. In
particular it is expected that there will be interaction with the AVT
Working Group relating to issues of running RTP over ST-II.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 94 Nov 94 <draft-ietf-st2-spec-01.txt, .ps>
Internet Stream Protocol Version 2 (ST2) Protocol
Specification - Version ST2+
Point-to-Point Protocol Extensions (pppext)
-------------------------------------------
Charter
Current status: active working group
Chair(s):
Fred Baker <fred@cisco.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive:
Description of Working Group:
The Point-to-Point Protocol (PPP) was designed to encapsulate multiple
protocols. IP was the only network layer protocol defined in the
original documents. The working group is defining the use of other
network layer protocols and options for PPP. The group will define the
use of protocols including: bridging, ISO, DECNET (Phase IV and V),
XNS, and others. In addition, it will define new PPP options for the
existing protocol definitions, such as stronger authentication and
encryption methods.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Mar 93 Apr 94 <draft-ietf-pppext-frame-relay-03.txt>
PPP in Frame Relay
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 May 94 <draft-ietf-pppext-magnalink-01.txt>
PPP Magnalink Variable Resource Compression
Apr 94 Jul 94 <draft-ietf-pppext-callback-cp-02.txt>
Proposal for Callback Control Protocol (CBCP).
Jul 94 New <draft-ietf-pppext-sdtp-00.txt>
PPP Serial Data Transport Protocol (SDTP)
Jul 94 New <draft-ietf-pppext-atcp2-00.txt>
The PPP AppleTalk Control Protocol (ATCP)
Jul 94 Nov 94 <draft-ietf-pppext-vines-01.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)
Nov 94 New <draft-ietf-pppext-xnscp-00.txt>
The PPP XNS IDP Control Protocol (XNSCP)
Nov 94 New <draft-ietf-pppext-encryption-00.txt>
The PPP Encryption Control Protocol (ECP)
Nov 94 New <draft-ietf-pppext-lzs-dcp-00.txt>
PPP LZS-DCP Compression Protocol (LZS-DCP)
Nov 94 New <draft-ietf-pppext-dce-compress-00.txt>
PPP for Data Compression in Data Circuit-Terminating Equipment
(DCE)
Service Location Protocol (svrloc)
----------------------------------
Charter
Current status: active working group
Chair(s):
John Veizades <veizades@wco.ftp.com>
Scott Kaplan <scott@wco.ftp.com>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:srv-location@ftp.com
To Subscribe: srv-location-request@ftp.com
Archive:
Description of Working Group:
The Service Location Protocol Working Group is chartered to investigate
protocols to find, and bind to, service entities in a distributed internetworked
environment. Issues that must be addressed are how such a protocol would
interoperate with existing directory-based service location protocols.
Protocols that would be designed by this group would be viewed as an adjunct
to directory service protocols. These protocols would be able to provide a
bridge between directory services and current schemes for service location.
The nature of the service location problem is investigative in
principle. There is no mandate that a protocol be drafted as part
of this process. It is the mandate of this group to understand the operation
of service location and then determine the correct action in their view,
whether it be to use current protocols to suggest a service location
architecture, or to design a new protocol to compliment current architectures.
Internet-Drafts:
Posted Revised I-D Title <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 <mak@aads.net>
Peter Ford <peter@goshawk.lanl.gov>
Internet Area Director(s):
Stev Knowles <stev@ftp.com>
Claudio Topolcic <topolcic@bbn.com>
Mailing lists:
General Discussion:tuba@lanl.gov
To Subscribe: tuba-request@lanl.gov
Archive:
Description of Working Group:
The TUBA Working Group will work on extending the Internet Protocol
suite and architecture by increasing the number of end-systems which
can be effectively addressed and routed. The TUBA effort will expand
the ability to route Internet packets by using addresses which support
more hierarchy than the current Internet Protocol (IP) address space.
TUBA specifies the continued use of Internet transport protocols, in
particular TCP and UDP, but specifies their encapsulation in ISO 8473
(CLNP) packets. This will allow the continued use of Internet
application protocols such as FTP, SMTP, TELNET, etc. An enhancement
to the current system is mandatory due to the limitations of the
current 32-bit IP addresses. TUBA seeks to upgrade the current system
by a transition from the use of IPv4 to
ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access
Point address space.
In addition to protocol layering issues and ``proof of concept'' work,
the TUBA approach will place significant emphasis on the engineering
and operational requirements of a large, global, multilateral public
data network. TUBA will work to maximize interoperatability with the
routing and addressing architecture of the global CLNP infrastructure.
The TUBA Working Group will work closely with the IETF NOOP and
OSI IDRP for IP Over IP Working Groups to coordinate a viable CLNP-based
Internet which supports the applications which Internet users depend on
such as TELNET, FTP, SMTP, NFS, X, etc. The TUBA Working Group will also
work collaboratively with communities which are using CLNP, and will
consider issues such as interoperability,
applications coexisting on top of multiple transports, and the
evolution of global public connectionless datagram networks, network
management and instrumentation using CLNP and TUBA, and impact on
routing architecture and protocols given the TUBA transition.
The TUBA Working Group will consider how the TUBA scheme will support
transition from the current IP address space to the future NSAP
address space without discontinuity of service, although different
manufacturers, service providers, and sites will make the transition
at different times. In particular, the way in which implementations
relying on current 32-bit IP addresses will migrate must be
considered. TUBA will ensure that IP addresses can be assigned, for
as long as they are used, independently of geographical and routing
considerations. One option is to embed IP addresses in NSAP addresses,
possibly as the NSAP end-system identifier. Whatever scheme is chosen
must run in a majority of *-GOSIPs and other NSAP spaces. The TUBA
strategy will require a new mapping in the DNS from NAMEs to NSAP
addresses.
The rationale RFC (RFC 1347) documents issues of transition and
coexistence, among unmodified IPv4 hosts and hosts which support
TUBA hosts. Hosts wishing full Internet connectivity will need to
support TUBA.
Internet-Drafts:
Posted Revised I-D Title <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
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 <ted.brunner@tek.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg@dbc.mtview.ca.us>
Mailing lists:
General Discussion:if-mib@thumper.bellcore.com
To Subscribe: if-mib-request@thumper.bellcore.com
Archive: thumper.bellcore.com:pub/tob/ifmib
Description of Working Group:
The Interfaces MIB Working Group is chartered to accomplish two tasks.
First, to develop a collection of managed objects which model the
relation between different entities in the data link and physical
layers. The working group will explore different modeling
approaches in order to develop a collection of objects which is
both correct in the modeling sense and has an acceptable impact (if
any) on the interfaces table from MIB-II and all media MIB modules
on the standards track or under development by a working group.
The objects defined by the working group will be consistent with
the SNMP framework.
Second, to prepare a recommendation to the IESG evaluating RFC 1229
(the interface-extensions MIB), RFC 1231 (the token-ring MIB), RFC 1304
(the SMDS MIB), and RFC 1398 (the ethernet-like MIB) with respect to the
standards track.
The recommendation will document implementation, interoperability,
and deployment experience. If these experiences suggest that
changes should be made to the documents, new drafts may be
prepared.
For RFCs 1229, 1231, and 1304, the recommendation will report one
of four outcomes for each RFC:
- that the RFC should be advanced from Proposed to Draft Standard status,
without changes (if no problems are found);
-that a draft prepared by the working group should replace
the RFC, and be designated a Draft Standard (if only minor changes
are made);
- that a draft prepared by the working group should
replace the RFC, and be designated a Proposed Standard (if major
changes or feature enhancements are made); or,
- that the RFC should be designated as Historic (if this technology
is problematic).
For RFC 1398, the recommendation will report one of five outcomes:
- that the RFC should be advanced from Draft Standard to Standard
status, without
changes (if no problems are found);
- that a draft prepared by the
working group should replace the RFC, and be designated a
Standard (if only editorial changes are made);
- that a draft
prepared by the working group should replace the RFCs, and be
designated a Draft Standard (if only minor changes are made);
- that
a draft prepared by the working group should replace the RFC, and
be designated a Proposed Standard (if major changes or feature
enhancements are made); or,
- that the RFC should be designated as
Historic (if this technology is problematic).
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 93 Jul 94 <draft-ietf-ifmib-conntable-02.txt>
Management Information Base for Management of Network
Connections
Jul 94 Oct 94 <draft-ietf-ifmib-tokenringmib-01.txt>
IEEE 802.5 MIB
Sep 94 Oct 94 <draft-ietf-ifmib-ssr-mib-01.txt>
IEEE 802.5 Station Source Routing MIB
Printer MIB (printmib)
----------------------
Charter
Current status: active working group
Chair(s):
Joel Gyllenskog <jgyllens@boi.hp.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg@dbc.mtview.ca.us>
Area Advisor
Steven Waldbusser <sw0l@andrew.cmu.edu>
Mailing lists:
General Discussion:pmi@hpbs907.boi.hp.com
To Subscribe: pmi-request@hpbs907.boi.hp.com
Archive: ftp://ftpboi.external.hp.com:/pub/snmpmib
Description of Working Group:
The Printer MIB Working Group is chartered to develop a set of managed
objects for networked printers. These objects will be the minimum
necessary to provide the ability to monitor and control these systems,
providing fault, configuration and performance management, and will be
consistent with the SNMP framework and existing SNMP standards.
At its discretion, the working group may also define a small number of
unsolicited notifications (traps) which carry these managed objects.
However, the working group recognizes that traps are used sparingly in
the SNMP framework.
The working group recognizes that the area of networked printers is
quite diverse. However, the working group is specifically confined to
defining managed objects that instrument critical information about:
- printer engine
- interpreters
- media
- input sources
- output destinations
- I/O interfaces
Further, the working group is specifically prohibited from defining
managed objects that define instrumentation about:
- other marking technologies (e.g., those that mark onto film)
- fonts
- spooling
- print job management
Internet-Drafts:
Posted Revised I-D Title <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):
Andy Bierman <abierman@cisco.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg@dbc.mtview.ca.us>
Area Advisor
Steven Waldbusser <sw0l@andrew.cmu.edu>
Mailing lists:
General Discussion:rmonmib@cs.hmc.edu
To Subscribe: rmonmib-request@cs.hmc.edu
Archive: jarthur.cs.hmc.edu:/pub/rmon
Description of Working Group:
The RMON MIB Working Group is chartered to define a set of managed
objects for remote monitoring of networks. These objects will be
the minimum necessary to provide the ability to monitor multiple
network layers of traffic in remote networks; providing fault,
configuration, and performance management, and will be consistent
with the SNMP framework and existing SNMP standards.
The working group will consider existing MIB modules that define
objects which support similar management, e.g., RFC 1271 and
RFC 1513 and efforts in other areas, e.g., the accounting and
operational statistics activities. It is possible that this RMON
will not be backwards compatible with existing RMON RFCs, but the
reasons for any such incompatibility will be well documented.
The following list of features for this RMON has been previously
discussed in relation to existing RMON functionality and is included
to focus these RMON activities. It is recognized that other issues
may be considered and that certain of the following issues may not
be part of the final specification:
1) Protocol-type distribution through all seven layers of the ISO
model.
2) Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa.
3) Mechanisms that enable the detection of duplicate addresses or
address changes.
4) The relationship of the Manager-to-Manager MIB in SNMPv2 and
associated RMON alarm related activities.
5) Host Table for the Network Layer and the Transport Layer.
6) Provide a simple mechanism for the specification of event/trap
destinations
7) Address the issue of the filter mechanism being constrained by
bit-to-bit packet matching, which presents a problem with variable-
length packets.
8) Consider how RMON could benefit network security, for example:
using the RMON History to provide an accountability and audit
trail up to the Transport Layer.
9) Provide performance metrics for the client-server environment.
10) Concerns of hardware implementation should be considered. For example,
optimization of the filter and capture group could reduce the cost of
the CPU and improve performance.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Feb 94 Oct 94 <draft-ietf-rmonmib-rmonmib-03.txt>
Remote Network Monitoring Management Information Base
SNA DLC Services MIB (snadlc)
-----------------------------
Charter
Current status: active working group
Chair(s):
Shannon Nix <snix@metaplex.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg@dbc.mtview.ca.us>
Area Advisor
Ken Key <key@tgv.com>
Mailing lists:
General Discussion:snadlcmib@cisco.com
To Subscribe: snadlcmib-request@cisco.com
Archive:
Description of Working Group:
The SNA DLC Services MIB Working Group is chartered to define a set of
managed
objects for the SDLC and LLC-2 data link controls for SNA
networks. These objects will be the minimum necessary to provide
the ability to monitor and control those devices, providing fault,
configuration, and performance management, and will be consistent
with the SNMP framework and existing SNMP standards.
The working group will consider existing enterprise-specific MIB modules
that define objects which support management of these devices. The
group may choose to consider any work done by the IEEE in the
area of managed object definition for LLC-2. It will also make sure
that its work is aligned with the SNA NAU Services MIB Working Group,
due to the close relationship between the devices being worked on by
the two groups.
The working group recognizes that managed objects for other SNA data
link controls and related components (e.g., QLLC, System/370 Channel,
Data Link Switching, and ESCON) may need to be identified in the
future. These objects are out of scope for the current charter;
however, once the group completes its charter, a new charter
identifying some or all of these components may be considered.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 93 Nov 94 <draft-ietf-snadlc-sdlc-mib-06.txt>
Definitions of Managed Objects for SNA Data Link Control: SDLC
Jul 94 Nov 94 <draft-ietf-snadlc-llc-mib-01.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 <zbig@cisco.com>
Deirdre Kostick <dck2@mail.bellcore.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg@dbc.mtview.ca.us>
Area Advisor
David Perkins <dperkins@synoptics.com>
Mailing lists:
General Discussion:snanaumib@thumper.bellcore.com
To Subscribe: snanaumib-request@thumper.bellcore.com
Archive: thumper.bellcore.com:pub/tob/snanaumib/archive
Description of Working Group:
The SNA NAU Services MIB Working Group is chartered to define a
set of managed objects for PU type 2.1 LEN nodes and LU type 6.2
devices for SNA networks. These objects will be the minimum
necessary to provide the ability to monitor and control those
devices, providing fault, configuration, and performance
management, and will be consistent with the SNMP framework and
existing SNMP standards.
The working group will consider existing enterprise-specific MIB
modules that define objects which support management of these
devices. It will also make sure that its work is aligned with the
SNA DLC Services MIB Working Group, due to the close relationship
between the devices being worked on by the two groups.
The working group recognizes that managed objects for other
components may need to be identified in the future. For example,
APPN end and network nodes are not included. These objects are out
of scope for the current charter; however, once the group
completes its charter, a new charter identifying some or all of
these components may be considered.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Jul 94 Oct 94 <draft-ietf-snanau-appcmib-01.txt>
Definitions of Managed Objects for APPC
SNMP Version 2 (snmpv2)
-----------------------
Charter
Current status: active working group
Chair(s):
Bob Stewart <bstewart@cisco.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg@dbc.mtview.ca.us>
Mailing lists:
General Discussion:snmpv2@tis.com
To Subscribe: snmpv2-request@tis.com
Archive: ftp.tis.com:/pub/ietf/snmpv2
Description of Working Group:
The SNMPv2 Working Group is chartered to prepare a recommendation
to the IESG evaluating RFCs 1441-1452 (the SNMPv2 document set)
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 Internet-Drafts may be prepared. The
recommendation will report one of four outcomes for each RFC:
- that the RFC should be advanced from Proposed to Draft status,
without changes (if no problems are found);
- that an Internet-Draft prepared by the working group should
replace the RFC, and be designated a Draft Standard (if only
minor changes are made);
- that an Internet-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>
------ ------- ------------------------------------------
Nov 94 New <draft-ietf-snmpv2-adminv2-ds-00.txt>
Administrative Model for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-sec-ds-00.txt>
Security Protocols for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-party-ds-00.txt>
Party MIB for Version 2 of the Simple Network Management
Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-proto-ds-00.txt>
Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-intro-ds-00.txt>
Introduction to Version 2 of the Internet-standard Network
Management Framework
Nov 94 New <draft-ietf-snmpv2-conf-ds-00.txt>
Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-tc-ds-00.txt>
Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-smi-ds-00.txt>
Structure of Management Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-tcp-ds-00.txt>
SNMPv2 Management Information Base for the Transmission Control
Protocol
Nov 94 New <draft-ietf-snmpv2-udp-ds-00.txt>
SNMPv2 Management Information Base for the User Datagram
Protocol
Nov 94 New <draft-ietf-snmpv2-mib-ds-00.txt>
Management Information Base for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-tm-ds-00.txt>
Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)
Nov 94 New <draft-ietf-snmpv2-m2m-ds-00.txt>
Manager-to-Manager Management Information Base
Nov 94 New <draft-ietf-snmpv2-coex-ds-00.txt>
Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework
Nov 94 New <draft-ietf-snmpv2-ip-ds-00.txt>
SNMPv2 Management Information Base for the Internet Protocol
Process for Organization of Internet Standards (poised)
-------------------------------------------------------
Charter
Current status: active working group
Chair(s):
Steve Crocker <crocker@cybercash.com>
Mel Pleasant <pleasant@noc.rutgers.edu>
None Director(s):
Paul Mockapetris <pvm@isi.edu>
Mailing lists:
General Discussion:poised@tis.com
To Subscribe: poised-request@tis.com
Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/*
Description of Working Group:
In 1992 and 1993, the POISED effort revised the responsibilities of
the IESG and IAB and instituted a selection process for filling
positions on these bodies. The ISOC Trustees gave interim approval
to these arrangements and asked that we revisit, revise and formalize
the arrangements after two rounds of selection had been completed.
The POISED Working Group will now review the current rules, propose
charters and rules for the IESG, IETF, IAB, IRSG, and IRTF, and submit
them to the ISOC Trustees after approval by the IETF.
There appears to be general consensus that the current assignments of
responsibility and the selection process are working moderately well,
so it is not anticipated that there will be large changes.
Nonetheless, some issues have been raised and need review. Among
these are:
o There is a complex interplay between the IETF area structure and the
selection process for the IESG. The IESG has the power to create,
split, merge and remove areas, but the nominations committee has the
responsibility to fill positions. The IESG needs some flexibility
to balance work loads, use its people effectively, and meet the
changing needs of the IETF. The current rules are not completely
clear as to how to handle all of the likely situations; these need to
be spelled out and agreed to.
o The nominations committee has non-voting liaisons from the IESG and
IAB. Both nominations committees also had current IAB or IESG
members, who volunteered and were selected at random, as voting
members. It has been suggested that current IESG and IAB members
carry too much weight in the deliberations and should be barred from
serving on the nominations committee.
o The selection and role of the nominations committee chair is somewhat
unclear. In particular, what power does the chair have to deal with
unresponsive committee members and/or to resolve disputes?
o At what point, if any, does the nominations committee's list of
candidates become public. This ties in with the apparent double-
standard of how publically incumbents vs. non-incumbents announce
their candidacy.
o The way to handle interim appointments is not clear. Two specific
issues are: who appoints interim members (and is ``ratification''
required), and how long does interim appointees serve?
o When the nominations committee has completed its work, it informs the
IAB and the ISOC Trustees. The procedures for doing so need to be
spelled out. At issue is when the nominations become public, whether
the community at large is invited to comment, and what to do if there
is difficulty in filling any of the positions.
o There is currently no specific mechanism for the IAB to use to
provide architectural guidance to working groups before the RFC
submission stage. POISED may discuss whether such a mechanism is
necessary, and if so, what that mechanism looks like.
o The role of the IRTF and research groups has not yet been defined.
o Should there be a regular mechanism for convening a POISED Working
Group in the future?
o The ISOC Trustees require that the procedures adopted meet with the
approval of counsel and the insurance carriers in order to protect
the Society from exposure. The procedures, rules, etc. adopted by
the community will most likely be satisfactory to counsel, but input
and review from counsel is essential.
In its deliberations, POISED may produce new documents (e.g., an IETF
Charter -- if the lack of such a charter delays the POISED effort),
and it may request changes to existing documents (e.g., ``The IAB
Charter'' [RFC 1601], ``The Internet Standards Process -- Version 2''
[RFC 1602], and ``IETF Working Group Guidelines and Procedures''
[RFC 1603]).
Internet-Drafts:
Posted Revised I-D Title <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 <mcquaid@wg.com>
Operational Requirements Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uunet.uu.net>
Mailing lists:
General Discussion:bmwg@harvard.edu
To Subscribe: bmwg-request@harvard.edu
Archive:
Description of Working Group:
The major goal of the Benchmarking Methodology Working Group is to make a
series of recommendations concerning the measurement of the performance
characteristics of different classes of network equipment and software
services.
Each recommendation will describe the class of equipment or service,
discuss the performance characteristics that are pertinent to that
class, specify a suite of performance benchmarks that test the described
characteristics, as well as specify the requirements for common
reporting of benchmark results.
Classes of network equipment can be broken down into two broad
categories. The first deals with stand-alone network devices such as
routers, bridges, repeaters, and LAN wiring concentrators. The second
category includes host-dependent equipment and services, such as network
interfaces or TCP/IP implementations.
Once benchmarking methodologies for stand-alone devices have matured
sufficiently, the group plans to focus on methodologies for testing
system-wide performance, including issues such as the responsiveness of
routing algorithms to topology changes.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Nov 94 New <draft-ietf-bmwg-methodology-00.txt>
Benchmarking Methodology for Network Interconnect Devices
Nov 94 New <draft-ietf-bmwg-overallperf-00.txt>
Benchmarking Methodologies for Overall Network Performance
CIDR Deployment (cidrd)
-----------------------
Charter
Current status: active working group
Chair(s):
Jessica Yu <jyy@merit.edu>
Vince Fuller <vaf@barrnet.net>
Operational Requirements Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uunet.uu.net>
Mailing lists:
General Discussion:bgpd@merit.edu
To Subscribe: bgpd-request@merit.edu
Archive: merit.edu: ~/pub/bgpd-archive
Description of Working Group:
The CIDR Deployment Working Group will be a forum for
coordinating the deployment, engineering, and operation of classless
routing protocols and procedures in the global Internet. This activity
will include, but not be limited to:
- Deployment of CIDR addressing and routing in the global Internet.
Will include coordination of deployment of new exterior routing
protocols, such as BGP4, which support CIDR.
- Develop mechanisms and procedures for sharing operational
information to aim the operation.
- Development of procedures, policies, and mechanisms to improve
the utilization efficiency of the IPv4 address space.
- Work on longer-term strategies for hierarchical, CIDR-based
addressing and routing. Examples include class A subnetting and
provider block sub-allocation along geographical/topological
boundaries as is done for 193.0.0.0 and 194.0.0.0 in Europe.
Initially, this working group will be simply the reincarnation of the
BGP Deployment Working Group under a new name.
Internet-Drafts:
No Current Internet-Drafts.
Generic Internet Service Description (gisd)
-------------------------------------------
Charter
Current status: active working group
Chair(s):
David Sitman <david@ccsg.tau.ac.il>
Operational Requirements Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uunet.uu.net>
Mailing lists:
General Discussion:gisd-wg@ripe.net
To Subscribe: majordomo@ripe.net
In Body: subscribe gisd-wg
Archive: ftp://ftp.ripe.net/ripe/archives/gisd-wg/current
Description of Working Group:
GISD collects short descriptions of Internet service aspects. Internet
service in GISD means the interaction of Internet service providers
among themselves and with their users. GISD aims to provide a
common frame of reference and vocabulary to talk about an Internet
service. For each aspect of the Internet service, it describes different
options for service provision in use in the current Internet. GISD is
merely descriptive and does not proscribe or mandate. The GISD document is
intended to be a living document, collecting the work of many contributors.
The GISD Working Group will update and revise the GISD document to
assist network service providers in a better understanding and description
of what Interent service means.
- Update and revise the GISD document that lists the areas and aspects of
interest to TCP/IP network service providers.
- Identify additional GISD areas and aspects appropriate to GISD.
- Identify areas of overlap with other IETF working groups.
- Create a reference document of GISD terms.
- Establish procedures to ensure the ongoing maintenance of the document
and identify an organization willing to do it.
Internet-Drafts:
No Current Internet-Drafts.
Network Status Reports (netstat)
--------------------------------
Charter
Current status: active working group
Chair(s):
Gene Hastings <hastings@psc.edu>
Operational Requirements Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uunet.uu.net>
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 <henryc@oar.net>
J. Nevil Brownlee <n.brownlee@auckland.ac.nz>
Operational Requirements Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uunet.uu.net>
Mailing lists:
General Discussion:oswg-l@wugate.wustl.edu
To Subscribe: oswg-l-request@wugate.wustl.edu
Archive: wuarchive.wustl.edu:~doc/mailing-lists/oswg-l
Description of Working Group:
Today there exists a variety of network management tools for
the collection and presentation of network statistical data.
Different kinds of measurements and presentation techniques
make it hard to compare data between networks. There exists a
need to compare these statistical data on a uniform basis to
facilitate cooperative management, ease problem isolation and
network planning.
The working group will try to define a model for network
statistics, a minimal set of common metrics, tools for
gathering statistical data, a common statistical database
storage format and common presentation formats. Collecting
tools will store data in a given format later to be retrieved
by presentation tools displaying the data in a predefined way.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 94 Nov 94 <draft-ietf-opstat-client-server-01.txt>
The Opstat Client-Server Model for Statistics Retrieval
IP Routing for Wireless/Mobile Hosts (mobileip)
-----------------------------------------------
Charter
Current status: active working group
Chair(s):
Kannan Alagappan <kannan@emc.com>
Tony Li <tli@cisco.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:mobile-ip@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe mobile-ip
Archive: playground.sun.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 Nov 94 <draft-ietf-mobileip-protocol-07.txt>
IP Mobility Support
IS-IS for IP Internets (isis)
-----------------------------
Charter
Current status: active working group
Chair(s):
Doug Montgomery <dougm@nist.gov>
Chris Gunner <gunner@lkg.dec.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:isis@merit.edu
To Subscribe: isis-request@merit.edu
Archive:
Description of Working Group:
The IS-IS for IP Internets Working Group will develop additions to the
existing OSI IS-IS routing protocol to support IP environments and dual OSI
and IP environments.
Internet-Drafts:
Posted Revised I-D Title <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 <A.Ballardie@cs.ucl.ac.uk>
Paul Francis <francis@slab.ntt.jp>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:idmr@cs.ucl.ac.uk
To Subscribe: idmr-request@cs.ucl.ac.uk
Archive: cs.ucl.ac.uk:/darpa/idmr-archive.Z
Description of Working Group:
Existing inter-domain multicast routing protocols are not scalable to
a large internetwork containing very large numbers of active
wide-area groups. The purpose of the IDMR Working Group, therefore,
is to discuss proposed inter-domain multicast routing protocols, and
put forward one (or a hybrid of several) as a Proposed Standard
to the IESG.
Several proposals have been made to date, including Core-Based Tree
(CBT) multicasting, Core-Based Join (CBJ) multicasting, and Scalable
Reverse Path Multicasting (SRPM). Some of the above have yet to be
reviewed.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
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 <msteenstrup@bbn.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:idpr-wg@bbn.com
To Subscribe: idpr-wg-request@bbn.com
Archive:
Description of Working Group:
The Inter-Domain Policy Routing Working Group is chartered to
develop an architecture and set of protocols for policy routing
among large numbers of arbitrarily interconnected administrative
domains.
Internet-Drafts:
No Current Internet-Drafts.
Inter-Domain Routing (idr)
--------------------------
Charter
Current status: active working group
Chair(s):
Sue Hares <skh@merit.edu>
Yakov Rekhter <yakov@watson.ibm.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:bgp@ans.net
To Subscribe: bgp-request@ans.net
Archive: merit.edu:/pub/archive/bgp
Description of Working Group:
The main list for this working group is "bgp@ans.net", but there is
also an IDRP-specific mailing list:
- List: idrp@merit.edu
- To Subscribe: idrp-request@merit.edu
- Archive: merit.edu:/pub/archive/idrp
The Inter-Domain Routing Working Group is chartered to standardize and
promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter-
Domain Routing Protocol (IDRP) as scalable inter-autonomous system
routing protocols capable of supporting policy based routing for TCP/IP
internets. The objective is to promote the use of BGP-4 to support
IP version 4 (IPv4). IDRP is seen as a protocol that will support
IPv4 as well as the next generation of IP (IPv6).
The working group will plan a smooth transition between BGP-4 and IDRP.
Documents:
1) BGP-4 (standards track)
This document contains the specification of the BGP protocol that
enables it to be used as a protocol for exchange of ``inter-
autonomous system information'' among routers to support forwarding
of IPv4 packets across multiple autonomous systems.
2) BGP-4 MIB (standards track)
This document contains the MIB definitions for BGP-4.
3) IDRP for IPv4 over IPv4 (standards track)
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support forwarding of IPv4 packets across multiple autonomous
systems.
4) IDRP MIB (standards track)
This document contains the MIB definitions for IDRP.
5) BGP/IDRP -- OSPF Interactions (standards track)
This document will specify the interactions between BGP/IDRP and
OSPF. This document will be based on a combination of the BGP -- OSPF
interactions, and IDRP -- IS-IS interaction documents.
6) BGP/IDRP for IPv4 Usage (standards track)
Most of IDRP for IPv4 Usage will reference the CIDR (supernetting)
RFCs and related Internet-Drafts. IDRP for IPv4 Usage will contain
a sample policy configuration language, and examples on how to use
IDRP for IPv4 in the Internet today.
7) IDRP for IPv6
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support the forwarding of IPv6 packets across multiple
autonomous systems.
8) IDRP for IP Next Generation Usage
The IDRP for IPv6 Usage document will contain instructions on
how to run IDRP for IPv6 over IPv4 and IPv6.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Sep 92 Oct 94 <draft-ietf-idr-bgp4ospf-interact-08.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)
Nov 94 New <draft-ietf-idr-idrp-v6-00.txt>
IDRP for IPv6
Nov 94 New <draft-ietf-idr-bgp4-experience-00.txt>
Experience with the BGP-4 protocol
Nov 94 New <draft-ietf-idr-bgp4-analysis-00.txt>
BGP-4 Protocol Analysis
Multicast Extensions to OSPF (mospf)
------------------------------------
Charter
Current status: active working group
Chair(s):
John Moy <jmoy@casc.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:mospf@comet.cit.cornell.edu
To Subscribe: mospf-request@comet.cit.cornell.edu
Archive:
Description of Working Group:
This working group will extend the OSPF routing protocol so that it
will be able to efficiently route IP multicast packets. This will
produce a new (multicast) version of the OSPF protocol, which will be
as compatible as possible with the present version (packet formats and
most of the algorithms will hopefully remain unaltered).
Internet-Drafts:
No Current Internet-Drafts.
New Internet Routing and Addressing Architecture (nimrod)
---------------------------------------------------------
Charter
Current status: active working group
Chair(s):
J. Noel Chiappa <jnc@lcs.mit.edu>
Isidro Castineyra <isidro@bbn.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:nimrod-wg@bbn.com
To Subscribe: nimrod-wg-request@bbn.com
Archive: bbn.com:/pub/nimrod-wg/nimrod-wg.archive
Description of Working Group:
The goal of the working group is to design, specify, implement and test a
flexible new routing and addressing architecture suitable for very large
scale internets. The basic architecture for computation of routes will
be based on distribution of network topology maps, with source-specified
route selection, and unitary (i.e., not hop-by-hop) computation of routes.
The architecture will provide a single homogeneous framework for all
routing, including both inter-domain and intra-domain. It will include a
new network component naming abstraction hierarchy, starting from network
attachment points, and based on actual connectivity, but taking into
consideration policy requirements. These new names will be variable
length, with a variable number of levels of abstraction; they will not
appear in most packets, though.
Actual packet forwarding will be based both on retained non-critical
state in the switches (via flow setup for long-lived communications), and
both classical address-only, as well as source-route type instructions, in
individual packets (for datagram applications which send only one, or a very
few, packets).
Although the general design and algorithms will be usable in any
internetworking protocol family, the initial detailed protocol
specifications and implementation are currently planned for deployment
with IPv4, but support for another packet format may be substituted or
added, depending on the situation in the Internet in the future.
Interoperabilty with existing unmodified IPv4 hosts will be achieved by
re-interpreting the existing source and destination fields in IPv4
packets as endpoint identifiers.
A substantial effort to take into account support for mobility,
multicast and resource allocation will be made when designing the Nimrod
architecture; provided that so doing is neither impossible because of
incomplete work outside the scope of Nimrod, nor the cause of very
substantial delays in the first iteration of the protocol design.
Internet-Drafts:
No Current Internet-Drafts.
Open Shortest Path First IGP (ospf)
-----------------------------------
Charter
Current status: active working group
Chair(s):
John Moy <jmoy@casc.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:ospf@gated.cornell.edu
To Subscribe: ospf-request@gated.cornell.edu
Archive:
Description of Working Group:
The OSPF Working Group will develop and field-test an SPF-based
Internal Gateway Protocol. The specification will be published and
written in such a way so as to encourage multiple vendor
implementations.
Internet-Drafts:
Posted Revised I-D Title <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
May 94 Nov 94 <draft-ietf-ospf-demand-01.txt>
Extending OSPF to support demand circuits
Aug 94 Oct 94 <draft-ietf-ospf-md5-02.txt>
OSPF MD5 Authentication
Nov 94 New <draft-ietf-ospf-ipv6-ext-00.txt>
OSPF IPv6 Extensions
Nov 94 New <draft-ietf-ospf-overflow-00.txt>
OSPF Database Overflow
RIP Version II (ripv2)
----------------------
Charter
Current status: active working group
Chair(s):
Gary Malkin <gmalkin@xylogics.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:ietf-rip@xylogics.com
To Subscribe: ietf-rip-request@xylogics.com
Archive: xylogics.com:gmalkin/rip/rip-arc
Description of Working Group:
RIP Version 2 and the Version 2 MIB was approved as a Proposed
Standard in January 1993. They were published as RFC 1388 and RFC 1389.
Since the mimimum required period has elapsed for a protocol
to remain as a Proposed Standard, RIP V2 can now be considered for
advancement to Draft Standard.
The RIP Version 2 Working Group will prepare a recommendation to the
IESG evalating the standards track status of RIP Version 2 and the
RIP Version 2 MIB. The recommendation will document implementation,
interoperability and deployment experience as required by RFC 1264
``Routing Protocol Criteria.''
This group is chartered to prepare revisions of ``RIP Version 2''
(RFC 1388), ``RIP Version 2 MIB'' (RFC 1389), and the analysis
document (RFC 1387) if necessary.
The RIP Version 2 Working Group is further chartered to evaluate the
proposal for ``Routing over Demand Circuits using RIP'' for standards
track consideration.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Nov 94 New <draft-ietf-ripv2-md5-00.txt>
RIP-II Cryptographic Authentication
Nov 94 New <draft-ietf-ripv2-ripng-00.txt>
RIP for IPv6
Router Requirements (rreq)
--------------------------
Charter
Current status: active working group
Chair(s):
Frank Kastenholz <kasten@ftp.com>
Bill Manning <bmanning@isi.edu>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Area Advisor
Stev Knowles <stev@ftp.com>
Mailing lists:
General Discussion:rreq@rice.edu
To Subscribe: rreq-request@rice.edu
Archive: ftp.sesqui.net:/pub/rreq
Description of Working Group:
The Router Requirements Working Group has the goal of publishing the
existing draft as an Historic RFC, then updating it to include
references to more recent work, such as OSPF, BGP, multicast, etc.
Unlike other groups, this is recognized as an on-going effort that
should result in a series of drafts. It is expected that a revised
requirements draft will be published on a regular basis.
The working group will also instigate, review, or (if appropriate)
produce additional RFCs on related topics. To date, group members have
produced draft documents discussing the operation of routers which are in
multiple routing domains (3 papers), TOS, and a routing table MIB.
The purposes of this project include:
- Defining what an IP router does in sufficient detail that
routers from different vendors are truly interoperable.
- Providing guidance to vendors, implementors, and purchasers of
IP routers.
The working group has decided that, unlike RFC 1009, the Router Requirements
document should not discuss link layer protocols or address resolution.
Instead, those topics should be covered in a separate Link Layer Requirements
document, applicable to hosts as well as routers. Whether this group will
create the Link Layer Requirements document is still to be determined.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Jan 94 Nov 94 <draft-ietf-rreq-iprouters-require-01.txt>
Requirements for IP Routers
Routing over Large Clouds (rolc)
--------------------------------
Charter
Current status: active working group
Chair(s):
Andy Malis <malis@maelstrom.timeplex.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:rolc@maelstrom.timeplex.com
To Subscribe: rolc-request@maelstrom.timeplex.com
Archive: cnri.reston.va.us:/ietf-mail-archive/rolc/
Description of Working Group:
Summary: This group is created to analyse and propose solutions to
those problems that arise when trying to perform IP routing over large
``shared media'' networks. Examples of these networks include SMDS, Frame
Relay, X.25, and ATM.
Definition:
Internetwork Layer: To avoid confusion with multiple meanings of
``network'' layer, we will use the term ``Internetwork'' layer to
unambiguously refer to that layer at which IP runs. This is the
layer at which IP routing functions. This is also the layer at which
CLNP, DECnet, etc. run.
Large cloud: A collection of ``end-points'' be they routers or hosts,
connected over a fabric such that communication can be established,
in the absence of policy restrictions, between any two such
entities. This communication within a cloud takes place using
addressing and capabilities below the ``Internetwork'' layer.
The connectivity may or may not require circuit setup before
communication. Such a collection is considered large if it is
infeasible for all routing entities on such a ``cloud'' to maintain
``adjacencies'' with all others. Examples include, but are not limited
to, ATM, Frame Relay, SMDS, and X.25 public services.
The group will investigate the operation of IP routing protocols and
services over ``Large Clouds.'' Whenever possible, solutions shall be
applicable to a range of ``cloud'' services. That is, the goal is a
single solution applicable to multiple kinds of large ``clouds'' be they
public or private, and independent of the specific technology used to
realize the ``cloud'' (even a very large bridged Ethernet). It is also an
objective that solutions, where possible, apply to network layer
protocols other than IP.
The problems the group will cover are:
A) The architectural implications of allowing direct communication
between entities which do not share a common IP network number. The
group will also entertain proposals on the use of a common IP network
number. If (as many believe) it is infeasible, an effort to document
the difficulties will be made.
B) The routing/information protocol required to allow direct
communication between two entities which were not directly
exchanging routing information. This will include address
resolution. The solution must couple closely to routing. It must
take into account realistic connectivity policies.
C) Operation of existing protocols between peers on such clouds. Are
any changes necessary or desirable? If changes are required, they will
be proposed to the relevant working group.
D) Consideration of how policy restrictions and constraints (such as
access control and policy-based routing paths) affect A, B, and C.
The group will also review the applicability of the work to ISDN and
POTS. These technologies have a prima-facia difference, in that the
number of simultaneous connections is much smaller. The implications of
this for routing and relaying at the Internetwork layer will need to be
explored further.
Internet-Drafts:
Posted Revised I-D Title <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 <estrin@usc.edu>
Tony Li <tli@cisco.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Mailing lists:
General Discussion:sdrp@catarina.usc.edu
To Subscribe: sdrp-request@catarina.usc.edu
Archive: catarina.usc.edu:~/pub/sdrp
Description of Working Group:
The SDR Working Group is chartered to specify and promote the use of SDRP
(Source Demand Routing Protocol) as an inter-domain routing protocol
capability in conjunction with IDRP and BGP inter-domain routing
protocols. The purpose of SDR is to support explicit selection of inter-
domain routes, to complement the implicit hop-hy-hop route selection
provided by BGP/IDRP. The group is also chartered to specify and promote
the use of a similar protocol for IPv6, referred to as the Explicit
Routing Protocol (ERP).
The goal of the SDR Working Group is to release the components of SDR as
``experimental'' IETF protocols and to obtain operational experience with
SDR in the Internet. Once there is enough experience with SDR, the
working group will submit the SDR components to the IESG for
standardization.
SDR has four components: packet formats for protocol control messages
and encapsulation of user datagrams, processing and forwarding of user
data and control messages, routing information distribution/collection
and route computation, configuration and usage.
The group's strategy is to:
(1) Define the format, processing and forwarding of user datagram and
control messages so that SDR can be used very early on as an efficient
means of supporting ``configured'' inter-domain routes. User packets
are encapsulated along with the source route and forwarded along the
``configured'' route. Routes are static at the inter-domain level, but
are not static in terms of the intra-domain paths that packets will
take between specified points in the SDR route. The impact of
encapsulation on MTU, ICMP, performance, etc., are among the issues that
must be evaluated before deployment.
(2) Develop simple schemes for collecting (a) dynamic domain-level
connectivity information and (b) route construction based on this
information, so that those domains that want to can make use of a
richer, and dynamic set of SDR routes.
(3) Apply the experience with SDR design and implementation to the
design and implementation of ERP.
(4) Develop SDR and ERP deployment plans.
(5) In parallel with (1), (2) and (3) , develop usage and configuration
documents and prototypes that demonstrate the utility of static-SDR and
simple-dynamic-SDR and ERP.
(6) After gaining some experience with the simple schemes for
distribution, develop a second generation of information distribution
and route construction schemes. The group hopes to benefit from
discussions with IDPR and NIMROD developers at this future stage because
the issues faced are similar. The route distribution and construction
mechanisms are common to both ERP and SDRP.
(7) Investigate the use of SDRP and ERP alternate routing as a mechanism
for supporting reservation traffic (e.g., based on RSVP). This will
require that we address integration of SDRP/ERP and multicast routing
(e.g., running PIM over SDRP/ERP), as well as the interface between
SDRP/ERP and RSVP. Moreover, we will investigate the construction of
SDRP/ERP routes that make use of some dynamic control information, in
additional to the more traditional hop count.
(8) The group will also investigate the addition of security options
into the SDRP/ERP forwarding and packet format specifications.
(9) Coordinate with the IDR and IPng Working Groups.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Jul 94 New <draft-ietf-sdr-route-construction-00.txt, .ps>
SDRP Route Construction
Oct 94 New <draft-ietf-sdr-erp-00.txt>
Explicit Routing Protocol (ERP) for IPv6
Nov 94 New <draft-ietf-sdr-IPv6-pack-00.txt>
The Concept of Packs
Authenticated Firewall Traversal (aft)
--------------------------------------
Charter
Current status: active working group
Chair(s):
Marcus Leech <mleech@bnr.ca>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:aft@unify.com
To Subscribe: aft-request@unify.com
Archive: ftp.unify.com:/ietf/aft
Description of Working Group:
The goal of the Authenticated Firewall Traversal Working Group is to
specify a protocol to address the issue of application-layer support
for firewall traversal. The working group intends to specify a
traversal protocol supporting both TCP and UDP applications with a
general framework for authentication of the firewall traversal. To
promote interoperability, the group will also propose a base
authentication technique for use within the general authentication
framework.
The output of the group will consist of a standards-track RFC(s)
describing the traversal protocol, the base authentication methods
and a reference implementation of the protocol, and base
authentication methods. The working group will start with the SOCKS
system described by David Koblas in his paper presented at the 1992
Usenix Security Symposium.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 94 New <draft-ietf-aft-socks-protocol-v5-00.txt>
SOCKS Protocol Version 5
Nov 94 New <draft-ietf-aft-socks-md5-auth-00.txt>
Key-seeded MD5 authentication for SOCKS
Authorization and Access Control (aac)
--------------------------------------
Charter
Current status: active working group
Chair(s):
Clifford Neuman <bcn@isi.edu>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:ietf-aac@isi.edu
To Subscribe: ietf-aac-request@isi.edu
Archive: prospero.isi.edu:~/pub/aac/*
Description of Working Group:
The goal of the Authorization and Access Control Working Group
is to develop guidelines and an Application Programming Interface
(API) through which network accessible applications can uniformly
specify access control information. This API will allow applications
to make access control decisions when clients are not local users,
might not be members of a common organization, and often not known to
the service or application in advance.
Several authentication mechanisms are in place on the Internet, but
most applications are written with local applications in mind and no
guidelines exist for supporting authorization and access control based
on the output of such authentication mechanisms. The CAT Working
Group developed the GSS-API, a common API to support authentication.
The AAC Working Group will develop a common API that accepts the
identity of a client (perhaps the output of the GSS-API), a reference
to an object to be accessed, and optionally an indication of the
operation to be performed. The API will return a list of authorized
operations or a yes/no answer that can be easily used by the
application.
A second, longer term purpose of the working group will be to
examine evolving mechanisms and architectures for authorization in
distributed systems and to establish criteria which enable
interworking of confidence and trust across systems. The working
group will develop additional goals and milestones related to
this purpose and will submit a revised charter once the appropriate
goals and milestones are determined. To the extent possible this
additional work will encourage evolution toward credential formats
that more readily allow support for or translation across multiple
mechanisms.
Internet-Drafts:
No Current Internet-Drafts.
Commercial Internet Protocol Security Option (cipso)
----------------------------------------------------
Charter
Current status: active working group
Chair(s):
Ron Sharp <r.l.sharp@att.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:cipso@wdl1.wdl.loral.com
To Subscribe: cipso-request@wdl1.wdl.loral.com
Archive: archive-server@wdl1.wdl.loral.com
Description of Working Group:
The Commercial Internet Protocol Security Option Working Group is
chartered to define an IP security option that can be used to pass security
information within and between security domains. This new security option
will be modular in design to provide developers with a single software
environment which can support multiple security domains.
The CIPSO protocol will support a large number of security domains. New
security domains will be registered with the Internet Assigned Numbers
Authority (IANA) and will be available with minimal difficulty to all
parties.
There is currently in progress another IP security option referred to as
IPSO (RFC 1108). IPSO is designed to support the security labels used by
the US Department of Defense. CIPSO will be designed to provide labeling for
the commercial, US civilian and non-US communities.
The Trusted Systems Interoperability Group (TSIG) has developed a document
which defines a structure for the proposed CIPSO option. The working group
will use this document as a foundation for developing an IETF CIPSO
specification.
Internet-Drafts:
No Current Internet-Drafts.
Common Authentication Technology (cat)
--------------------------------------
Charter
Current status: active working group
Chair(s):
John Linn <john.linn@ov.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:cat-ietf@mit.edu
To Subscribe: cat-ietf-request@mit.edu
Archive: bitsy.mit.edu:~/cat-ietf/archive
Description of Working Group:
The goal of the Common Authentication Technology Working Group is to
provide strong authentication to a variety of protocol callers in a
manner which insulates those callers from the specifics of underlying
security mechanisms. By separating security implementation tasks from
the tasks of integrating security data elements into caller protocols,
those tasks can be partitioned and performed separately by
implementors with different areas of expertise. This provides
leverage for the IETF community's security-oriented resources, and
allows protocol implementors to focus on the functions their protocols
are designed to provide rather than on characteristics of security
mechanisms. CAT seeks to encourage uniformity and modularity in
security approaches, supporting the use of common techniques and
accommodating evolution of underlying technologies.
In support of these goals, the working group will pursue several
interrelated tasks. We will work towards agreement on a common
service interface allowing callers to invoke security services, and
towards agreement on a common authentication token format,
incorporating means to identify the mechanism type in conjunction with
which authentication data elements should be interpreted. The CAT
Working Group will also work towards agreements on suitable underlying
mechanisms to implement security functions; two candidate
architectures (Kerberos V5, based on secret-key technology and
contributed by MIT, and X.509-based public-key Distributed
Authentication Services being prepared for contribution by DEC) are
under current consideration. The CAT Working Group will consult with
other IETF working groups responsible for candidate caller protocols,
pursuing and supporting design refinements as appropriate.
Internet-Drafts:
Posted Revised I-D Title <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 Oct 94 <draft-ietf-cat-spkmgss-01.txt>
The Simple Public-Key GSS-API Mechanism (SPKM)
Nov 94 New <draft-ietf-cat-gssv2-00.txt>
Generic Security Service Application Program Interface, Version
2
Nov 94 New <draft-ietf-cat-iop-gss-00.txt>
Independent Object Protection Generic Security Service
Application Program Interface (IOP-GSS-API)
DNS Security (dnssec)
---------------------
Charter
Current status: active working group
Chair(s):
James Galvin <galvin@tis.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:dns-security@tis.com
To Subscribe: dns-security-request@tis.com
Archive: ftp.tis.com:/pub/dns-security
Description of Working Group:
The Domain Name System Security Working Group (DNSSEC) will
specify enhancements to the DNS protocol to protect the DNS against
unauthorized modification of data and against masquerading of data
origin. That is, it will add data integrity and authentication
capabilities to the DNS. The specific mechanism to be added to the DNS
protocol will be a digital signature.
The digital signature service will be added such that the DNS resource
records will be signed and, by distributing the signatures with the
records, remote sites can verify the signatures and thus have
confidence in the accuracy of the records received.
There are at least two issues to be explored and resolved. First,
should the records be signed by the primary or secondary (or both)
servers distributing the resource records, or should they be signed by
the start of authority for the zone of the records. This issue is
relevant since there are servers for sites that are not IP connected.
Second, the mechanism with which to distribute the public keys
necessary to verify the digital signatures must be identified.
Two essential assumptions have been identified. First, backwards
compatibility and co-existence with DNS servers and clients that do not
support the proposed security services is required. Second, data in
the DNS is considered public information. This latter assumption means
that discussions and proposals involving data confidentiality and
access control are explicitly outside the scope of this working group.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Feb 94 Nov 94 <draft-ietf-dnssec-secext-02.txt>
Domain Name System Protocol Security Extensions
Nov 94 New <draft-ietf-dnssec-as-map-00.txt>
Mapping Autonomous Systems Number into the Domain Name System
Internet Protocol Security Protocol (ipsec)
-------------------------------------------
Charter
Current status: active working group
Chair(s):
James Zmuda <zmuda@spyrus.com>
Paul Lambert <paul_lambert@email.mot.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:ipsec@ans.net
To Subscribe: ipsec-request@ans.net
Archive: ftp.ans.net:~/pub/archive/ipsec
Description of Working Group:
Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP.
A security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality. The
protocol formats for the IP Security Protocol (IPSP) will be independent of
the cryptographic algorithm. The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and
host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security. The key
management will be specified as an application layer protocol that is
independent of the lower layer security protocol. The protocol will
initially support public key-based techniques. Flexibility in the
protocol will allow eventual support of Key Distribution Center (KDC -
such as Kerberos) and manual distribution approaches.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 94 New <draft-ietf-ipsec-aziz-skip-00.txt>
Simple Key-Management For Internet Protocols (SKIP)
Network Access Server Requirements (nasreq)
-------------------------------------------
Charter
Current status: active working group
Chair(s):
Allan Rubens <acr@merit.edu>
John Vollbrecht <jrv@merit.edu>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:nas-req@merit.edu
To Subscribe: nas-req-request@merit.edu
Archive: merit.edu:/pub/nas-req-archive
Description of Working Group:
The Network Access Server Requirements Working Group has as its primary
goal, to identify functions and services that should be present in IP
Network Access Servers (NASs) and to specify the standards that
provide for these functions and services. The term ``Network Access
Server'' is used instead of the more conventional term ``Terminal Server''
as it more accurately describes the functions of interest to this
group. A ``Network Access Server'' is a device that provides for the
attachment of both traditional ``dumb terminals'' and terminal emulators
as well as workstations, PCs or routers utilizing a serial line
framing protocol such as PPP or SLIP. A NAS is viewed as a device that
sits on the boundary of an IP network, providing serial line points of
attachment to the network. A NAS is not necessarily a separate
physical entity; for example, a host system supporting serial line
attachments is viewed as providing NAS functionality and should abide
by NAS requirements.
This group will adopt (or define, if need be) a set of standard
protocols to meet the needs of organizations providing network access.
The immediate needs to be addressed by the group are in the areas of
authentication, authorization, and accounting. In general, this
group will select a set of existing standards as requirements for a
NAS. If necessary, the group will identify areas of need where
Internet standards do not already exist and new standardization efforts
may be required.
Initially the group will independently investigate the two cases of
character and frame-oriented access to the NAS. This investigation
will be aimed at determining what work is being done, or needs to be
done, in this and other working groups in order to be able to define
the set of NAS requirements. While the ultimate goal of this group is
to produce a NAS requirements document, it may be necessary to define
standards as well. This initial investigation will help determine what
the goals of this group need to be. The group will also work with
appropriate working groups to define required NAS standards that fall
into the areas of these other groups.
Internet-Drafts:
Posted Revised I-D Title <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 <kent@bbn.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:pem-dev@tis.com
To Subscribe: pem-dev-request@tis.com
Archive: pem-dev-request@tis.com
Description of Working Group:
PEM is the outgrowth of work by the Privacy and Security
Research Group (PSRG) of the IRTF. At the heart of PEM is a set of
procedures for transforming RFC 822 messages in such a fashion as to
provide integrity, data origin authenticity, and, optionally,
confidentiality. PEM may be employed with either symmetric or
asymmetric cryptographic key distribution mechanisms. Because the
asymmetric (public-key) mechanisms are better suited to the large
scale, heterogeneously administered environment characteristic of the
Internet, to date only those mechanisms have been standardized. The
standard form adopted by PEM is largely a profile of the CCITT X.509
(Directory Authentication Framework) recommendation.
PEM is defined by a series of documents. The first in the
series defines the message processing procedures. The second defines
the public-key certification system adopted for use with PEM.
The third provides definitions and identifiers for various
algorithms used by PEM. The fourth defines message formats and conventions for
user registration, Certificate Revocation List (CRL) distribution,
etc. (The first three of these were previously issued as RFCs 1113,
1114 and 1115. All documents have been revised and are being issued
first as Internet-Drafts.)
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Nov 92 Nov 94 <draft-ietf-pem-mime-07.txt>
PEM Security Services and MIME
Jun 94 Nov 94 <draft-ietf-pem-sigenc-02.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 <fglover@zk3.dec.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Mailing lists:
General Discussion:tnfs@wdl1.wdl.loral.com
To Subscribe: tnfs-request@wdl1.wdl.loral.com
Archive: archive-server@wdl1.wdl.loral.com
Description of Working Group:
The Trusted Network File System Working Group is chartered to define
protocol extensions to the Network File System (NFS) Version 2 protocol
which supports network file access in a Multilevel Secure (MLS) Internet
environment. MLS functionality includes Mandatory Access Control (MAC),
Discretionary Access Control (DAC), authentication, auditing, documentation,
and other items as identified in the Trusted Computer System Evaluation
Criteria (TCSEC) and Compartmented Mode Workstation (CMW) documents.
The primary objective of this working group is to specify extensions to the
NFS V2 protocol which support network file access between MLS systems. It
is intended that these extensions introduce only a minimal impact on
the existing NFS V2 environment, and that unmodified NFS V2 clients and
servers continue to be fully supported.
Transferring information between MLS systems requires exchanging additional
security information along with the file data. The general approach to be
used in extending the NFS V2 protocol is to transport additional user context
in the form of an extended NFS UNIX style credential between a Trusted NFS
(TNFS) client and server, and to map that context into the appropriate server
security policies which address file access. In addition, file security
attributes are to be returned with each TNFS procedure call. Otherwise,
the NFS V2 protocol remains essentially unchanged.
The Trusted System Interoperability Group (TSIG) has already developed a
specification which defines a set of MLS extensions for NFS V2, and has also
planned for the future integration of Kerberos as the authentication mechanism.
The TNFS Working Group should be able to use the TSIG Trusted NFS document
as a foundation.
Internet-Drafts:
Posted Revised I-D Title <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 <casner@isi.edu>
Transport Area Director(s):
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:rem-conf@es.net
To Subscribe: rem-conf-request@es.net
Archive: nic.es.net:pub/mailing-lists/mail-archive/rem-conf
Description of Working Group:
The Audio/Video Transport Working Group was formed to specify experimental
protocols for real-time transmission of audio and video over UDP
and IP multicast. The focus of this group is near-term and its
purpose is to integrate and coordinate the current AVT
efforts of existing research activities. No standards-track
protocols are expected to be produced because UDP transmission of
audio and video is only sufficient for small-scale experiments
over fast portions of the Internet. However, the transport
protocols produced by this working group should be useful on a larger scale
in the future in conjunction with additional protocols to access
network-level resource management mechanisms. Those mechanisms,
research efforts now, will provide low-delay service and guard
against unfair consumption of bandwidth by audio/video traffic.
Similarly, initial experiments can work without any connection
establishment procedure so long as a priori agreements on port
numbers and coding types have been made. To go beyond that, we
will need to address simple control protocols as well. Since IP
multicast traffic may be received by anyone, the control
protocols must handle authentication and key exchange so that the
audio/video data can be encrypted. More sophisticated connection
management is also the subject of current research. It is
expected that standards-track protocols integrating transport,
resource management, and connection management will be the result
of later working group efforts.
The AVT Working Group may design independent protocols specific to each
medium, or a common, lightweight, real-time transport protocol
may be extracted. Sequencing of packets and synchronization
among streams are important functions, so one issue is the form
of timestamps and/or sequence numbers to be used. The working group will
not focus on compression or coding algorithms which are domain of
higher layers.
Internet-Drafts:
Posted Revised I-D Title <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
Mar 94 Nov 94 <draft-ietf-avt-cellb-profile-02.txt>
RTP Encapsulation of CellB Video Encoding
Nov 94 New <draft-ietf-avt-jpeg-00.txt>
RTP Encapsulation of JPEG-compressed video.
Integrated Services (intserv)
-----------------------------
Charter
Current status: active working group
Chair(s):
Craig Partridge <craig@bbn.com>
Scott Shenker <shenker@parc.xerox.com>
John Wroclawski <jtw@lcs.mit.edu>
David Clark <ddc@lcs.mit.edu>
Transport Area Director(s):
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:int-serv@isi.edu
To Subscribe: int-serv-request@isi.edu
Archive: ftp.isi.edu:int-serv/int-serv.mail
Description of Working Group:
Recent experiments demonstrate the capability of packet switching
protocols to support Integrated Services --- the transport of audio,
video, real-time, and classical data traffic within a single network
infrastructure. These experiments suggest that expanding the Internet
service model would better meet the needs of these diverse applications.
The purpose of this working group is to specify this enhanced service model
and then to define and standardize certain interfaces and requirements
necessary to implement the new service model.
The working group will focus on defining a minimal set of global
requirements which transition the Internet into a robust
integrated-service communications infrastructure. Enhancements to
individual protocols (e.g., adding additional routing information to
routing protocols, or choosing IP queueing disciplines for routers)
will be left to other working groups, except in those rare cases where
detailed definitions of behavior are critical to the success of the
enhanced architecture.
Extending the Internet service model raises a series of questions.
The working group will focus on the three problems listed below:
(1) Clearly defining the services to be provided. The first task faced
by this working group is to define and document the enhanced Internet
service model.
(2) Defining the application service, router scheduling and (general)
subnet interfaces. The working group must define at least three
high-level interfaces: that expressing the application's end-to-end
requirements, that defining what information is made available to
individual routers within the network, and the additional expectations
(if any) the enhanced service model has for subnet technologies. The
working group will define these abstract interfaces, and will coordinate
with and advise IP over "subnet" working groups (such as IP over ATM)
in this.
(3) Developing router validation requirements which can ensure that
the proper service is provided. We assume that the Internet will
continue to contain a heterogeneous set of routers, running different
routing protocols and using different forwarding algorithms. The
working group will seek to define a minimal set of additional router
requirements which ensure that the Internet can support the new
service model. Rather than presenting specific scheduling and admission
control algorithms which must be supported, these requirements will likely
take the form of behavioral tests which measure the capabilities of
routers in the integrated services environment. This approach is used
because no single algorithm seems likely to be appropriate in all
circumstances at this time. The working group will coordinate with
the Benchmarking Working Group (BMWG).
We expect to generate three RFCs as a product of performing these tasks.
An important aspect of this working group's charter is in coordination
with the development of IP Next Generation. The working group will
be reviewed in November 1995 to determine if it should be re-chartered
as is or modified to reflect IPng developments, in particular, but also
operational and commercial developments. The IESG deems the great
significance of this working group to merit this unusual review.
In addition, because many of the integrated services concepts are new,
the working group may produce Informational RFCs explaining specific
algorithms that may be appropriate in certain circumstances, and may host
some educational meetings to assist both IETF members and members of the
larger Internet community to understand the proposed enhancements to IP.
The working group proposes to hold regular meetings beyond those held at
the IETF meetings.
APPENDIX - Integrated Services Working Group Management Plan
The general chair is Craig Partridge (BBN). The co-chairs are Dave Clark
(MIT), Scott Shenker (XEROX), and John Wroclawski (MIT).
The dual reasons for this management structure are:
(1) The working group will have do considerably more outreach into the
larger networking community than the typical IETF working group. For
instance, one of the important tasks is to convince the larger public
that IP is suitable for integrated services. So we need management
manpower to do outreach.
(2) The working group has a lot of work to do and swiftly. Even though
we plan to spin off working groups as fast as we can, a lot of key
architectural decisions will need to be made in one place (e.g., by
this working group) if the final architecture is to be sound. So we
need management manpower just to keep the working group moving.
So Craig has primary responsibility for keeping the working group moving,
and Dave, Scott, and John have primary responsibility for outreach to
different communities (and titles sufficient to show they can speak for
the working group).
Internet-Drafts:
No Current Internet-Drafts.
Multiparty Multimedia Session Control (mmusic)
----------------------------------------------
Charter
Current status: active working group
Chair(s):
Eve Schooler <schooler@cs.caltech.edu>
Abel Weinrib <AWeinrib@ibeam.intel.com>
Transport Area Director(s):
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp.isi.edu:~/confctrl/confcrtl.mail
Description of Working Group:
The demand for Internet multimedia teleconferencing has arrived, yet an
infrastructure to support this demand is barely in place. Multimedia
session control, defined as the management and coordination of multiple
sessions and their multiple users in multiple media (e.g., audio,
video), is one component of the infrastructure. The Multiparty
Multimedia Session Control Working Group is chartered to design and
specify a protocol to perform these functions.
The protocol will provide negotiation for session membership,
underlying communication topology and media configuration. In
particular, the protocol will support a user initiating a multimedia
multiparty session with other users (``calling'' other users) over the
Internet by allowing a teleconferencing application on one workstation
to explicitly rendezvous with teleconferencing applications running on
remote workstations. Defining a standard protocol will enable
session-level interoperability between different teleconferencing
implementations.
The focus of the working group is to design a session agreement
protocol that supports tightly-controlled conferences in addition to
the loosely-controlled ones currently carried on the MBone.
Loosely-controlled sessions have little to no interaction among
members, thus limiting their ability to provide security or
coordination of session attributes (e.g., quality-of-service options
for time-critical media, floor control for media flows). Users may
learn of loosely-controlled sessions using the ``sd'' utility or other
out of band mechanisms (e.g., e-mail, WWW). However, there is clearly
also a need for more tightly-controlled sessions that provide
mechanisms for directly contacting other users to initiate a conference
and for negotiating conference parameters such as membership, media
encodings and encryption keys. In addition, these sessions should
support renegotiation during a session, for example, to add or delete
members or change the media encoding.
The main goal of the working group will be to specify the session
control protocol for use within teleconferencing software over the
Internet. The working group will focus on the aspects of the session
control problem that are well understood, while keeping an eye on
evolving research issues. Toward this end, the working group has made
an inventory of existing conferencing systems and their session control
protocols. The working group will document the requirements of the
existing prototypes as a basis for the protocol development. The
working group will iteratively refine the protocol based on
implementation and operational experience.
Furthermore, the working group will coordinate with other efforts
related to multimedia conferencing, such as directory services
for cataloging users and conferences, the RTP and RTCP protocols
developed by the Audio/Video Transport Working Group, resource
reservation and management at the network level, and schemes for
multicast address allocation.
Internet-Drafts:
No Current Internet-Drafts.
ONC Remote Procedure Call (oncrpc)
----------------------------------
Charter
Current status: active working group
Chair(s):
Raj Srinivasan <raj.srinivasan@eng.sun.com>
Transport Area Director(s):
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:oncrpc-wg@sunroof.eng.sun.com
To Subscribe: oncrpc-wg-request@sunroof.eng.sun.com
Archive: playground.sun.com: pub/oncrpc
Description of Working Group:
The purpose of the Open Network Computing Remote Procedure Call
Working Group is to update the RFCs that
describe ONC RPC to reflect the current state of the deployed and
accepted technology, and submit them for Internet standardization.
ONC RPC is currently described in ``RPC: Remote Procedure Call
Protocol Specification Version 2'' (RFC 1057), and ``XDR: External
Data Representation Standard'' (RFC 1014).
The focus of the ONC-RPC Working Group is to document and standardize
the current ONC RPC protocols. It is not the intent of this working group
to develop extensions to these protocols. However, once these tasks are
completed, discussions of future enhancements are expected. These
discussions could lead to a follow on working group.
Background:
ONC RPC is a Remote Procedure Call technology that originated in Sun
Microsystems in the early 1980s. ONC RPC was modelled on Xerox's
Courier RPC protocols. It has been widely deployed on platforms from
most major workstation vendors. It has been implemented on MS-DOS,
Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and
practically all flavors of UNIX, among others. Sun Microsystems plans
to give the ownership of ONC RPC and change control over the ONC RPC
protocols to the IETF.
Internet-Drafts:
Posted Revised I-D Title <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 <braden@isi.edu>
Lixia Zhang <lixia@parc.xerox.com>
Transport Area Director(s):
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:rsvp@isi.edu
To Subscribe: rsvp-request@isi.edu
Archive: ftp.isi.edu:rsvp/rsvp.mail
Description of Working Group:
RSVP is a resource reservation setup protocol for the Internet. Its
major features include: (1) the use of ``soft state'' in the routers, (2)
receiver-controlled reservation requests, (3) flexible control over
sharing of reservations and forwarding of subflows, and (4) the use of
IP multicast for data distribution.
The primary purpose of this working group is to evolve the RSVP
specification and to introduce it into the Internet standards track.
The working group will also serve as a meeting place and forum for
those developing and experimenting with RSVP implementations.
The task of the RSVP working group, creating a robust specification for
real-world implementations of RSVP, will require liaison with two other
efforts: (1) continuing research and development work on RSVP in the
DARTnet research
community, and (2) the parallel IETF working group that is considering
the service model for integrated service. Although RSVP is largely
independent of the service model, its design does depend upon the
overall integrated service architecture and the requirements of
real-time applications. As an additional task, RSVP will maintain
coordination with the IPng-related working groups.
Internet-Drafts:
Posted Revised I-D Title <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 <dab@cray.com>
Transport Area Director(s):
Allison Mankin <mankin@cmf.nrl.navy.mil>
Mailing lists:
General Discussion:tcplw@cray.com
To Subscribe: tcplw-request@cray.com
Archive:
Description of Working Group:
The TCP Large Windows Working Group is chartered to produce a
specification for the use of TCP on high-delay, high-bandwidth paths.
To this end, this working group recommended ``TCP extensions for
long-delay paths'' (RFC 1072), and ``TCP Extension for High-Speed
Paths'' (RFC 1185)
be published jointly as a Proposed Standard. Deficiencies in
the technical details of the documents were identified by the
End-to-End Research Group of the IRTF. Rather than progress the
standard with known deficiencies, the IESG tasked the End-to-End
Research Group to fix and merge these two documents into a single
protocol specification document. This review was done on the
e2e-interest@isi.edu mailing list.
The TCP Large Windows Working Group is being resurrected for a one
time meeting, to review and if appropriate, approve this new document.
Internet-Drafts:
No Current Internet-Drafts.
Integrated Directory Services (ids)
-----------------------------------
Charter
Current status: active working group
Chair(s):
Linda Millington <l.millington@cdl.cdc.com>
Sri Sataluri <sri@qsun.att.com>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:ids@merit.edu
To Subscribe: ids-request@merit.edu
Archive: merit.edu:~/pub/ids-archive
Description of Working Group:
The Integrated Directory Services Working Group is chartered to
facilitate the integration and interoperability of current and future
directory services into a unified directory service. This work will
unite directory services based on a heterogeneous set of directory
services protocols (X.500, WHOIS++, etc.). In addition to specifying
technical requirements for the integration, the IDS Working Group will also
contribute to the administrative and maintenance issues of directory
service offerings by publishing guidelines on directory data integrity,
maintenance, security, and privacy and legal issues for users and
administrators of directories.
IDS will also assume responsibility for the completion of the
outstanding Directory Information Services Infrastructure (DISI)
Internet-Drafts, which are all specific to X.500, and for
the maintenance of ``A catalog of available X.500 implementations''
(FYI 11).
IDS will need to liase with the groups working on development and
deployment of the various directory service protocols.
The IDS Working Group is a combined effort of the Applications Area and
the User Services Area of the IETF.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Nov 94 New <draft-ietf-ids-x500-pds-directory-00.txt>
Recommendations for an X.500 Production Directory Service
Integration of Internet Information Resources (iiir)
----------------------------------------------------
Charter
Current status: active working group
Chair(s):
Chris Weider <clw@bunyip.com>
Kevin Gamiel <kevin.gamiel@cnidr.org>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:iiir@merit.edu
To Subscribe: iiir-request@merit.edu
Archive: merit.edu:~/pub/iiir-archive
Description of Working Group:
The Integration of Internet Information Resources Working Group (IIIR)
is chartered to facilitate interoperability between Internet
information services, and to develop, specify, and align protocols
designed to integrate the plethora of Internet information services
(WAIS, ARCHIE, Prospero, etc.) into a single ``virtually unified
information service'' (VUIS). Such protocols would include, but are not
limited to, update protocols for distributed servers, a ``query routing
protocol'' to pass queries between existing services, protocols for
gateways between existing and future services, and standard exchange
formats (perhaps based on Z39.50) for cross-listing specific
information.
Also, where necessary, IIIR will create technical documentation for
protocols used for information services in the Internet.
Internet-Drafts:
Posted Revised I-D Title <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 Nov 94 <draft-ietf-iiir-publishing-02.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 <sellers@quest.arc.nasa.gov>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:isn-wg@unmvma.unm.edu
To Subscribe: listserv@unmvma.unm.edu
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>
------ ------- ------------------------------------------
Apr 94 Apr 94 <draft-ietf-isn-aup-01.txt>
Acceptable Use Policy Definition
Oct 94 New <draft-ietf-isn-expectations-00.txt>
Ways to Define User Expectations
Network Information Services Infrastructure (nisi)
--------------------------------------------------
Charter
Current status: active working group
Chair(s):
April Marine <amarine@atlas.arc.nasa.gov>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:nisi@merit.edu
To Subscribe: nisi-request@merit.edu
Archive:
Description of Working Group:
The NISI Working Group will explore the requirements for common, shared
Internet-wide network information services. The goal is to develop an
understanding for what is required to implement an information services
``infrastructure'' for the Internet. The work will begin with existing
NIC functions and services and should build upon work already being
done within the Internet community. A primary goal of the group is to
facilitate the development of relationships between NICs that will
result in the presentation of a seamless user support service. NISI
will work with all NICs, including the InterNIC, to achieve the goal of
a fully-functioning, cooperative mesh of worldwide NICs. In addition
to creating policies for interaction, NISI will address areas such as
common information formats, methods of access, user interface, and
issues relating to security and privacy of Internet databases.
Internet-Drafts:
Posted Revised I-D Title <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 <Jill.Foster@newcastle.ac.uk>
Mark Prior <mrp@itd.adelaide.edu.au>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:us-wg@nic.near.net
To Subscribe: us-wg-request@nic.near.net
Archive: ftp.near.net:/mail-archives/us-wg*
Description of Working Group:
Widespread familiarity with global network services and competence in
using them brings benefit to individual users, enriches the information
skills and resources of the community and optimizes the return in
investment in networked services.
The Network Training Materials Working Group is chartered to enable the
research community to make better use of the networked services.
Towards this end, the working group will work to provide a mix of
training materials for the broad academic community which will:
(1) enable user support staff to train users to use the networked services,
and (2) provide users with self-paced learning material. In the first
instance, it will not deal with operational training.
This working group is the IETF component of a joint RARE/IETF group
working on network training materials.
The working group will create a catalogue of existing network training
materials (using the IAFA style Data Elements where appropriate),
identify the gaps in network training materials and work to identify
the problems associated with hands on training workshops using
networked services providing a real service.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Oct 94 Nov 94 <draft-ietf-trainmat-catalogue-01.txt>
Catalogue of Network Training Materials
Responsible Use of the Network (run)
------------------------------------
Charter
Current status: active working group
Chair(s):
Sally Hambridge <sallyh@ludwig.intel.com>
Gary Malkin <gmalkin@xylogics.com>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:ietf-run@mailbag.intel.com
To Subscribe: majordomo@mailbag.intel.com
In Body: subscribe ietf-run <your-email-address>
Archive: ftp.intel.com/pub/ietf-run
Description of Working Group:
Reflecting the needs of the Internet community, the IETF sees a
need to create an etiquette ("netiquette" in network parlance)
guide for Internet users. The working group will develop an
FYI RFC on responsible use of the Internet and its tools.
Internet-Drafts:
No Current Internet-Drafts.
Site Security Handbook (ssh)
----------------------------
Charter
Current status: active working group
Chair(s):
Barbara Fraser <byf@cert.org>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:ssphwg@cert.sei.cmu.edu
To Subscribe: ssphwg-request@cert.sei.cmu.edu
Archive: info.cert.org:/pub/ietf/ssh
Description of Working Group:
The Site Security Handbook Working Group is chartered to create two
documents: (1) a revised handbook that will help system and network
administrators develop their own site-specific policies and procedures
to deal with computer security problems and their prevention and (2) a
new handbook for users. The text of these documents will be developed
from the existing RFC 1244, plus needed revisions and additions.
Internet-Drafts:
No Current Internet-Drafts.
Uniform Resource Identifiers (uri)
----------------------------------
Charter
Current status: active working group
Chair(s):
Larry Masinter <masinter@parc.xerox.com>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:uri@bunyip.com
To Subscribe: uri-request@bunyip.com
Archive: archives.cc.mcgill.ca:~/pub/mailing-lists/uri-archive
Description of Working Group:
The Uniform Resource Identifiers Working Group is chartered to
define a set of standards for the encoding of system-independent
resource location and identification information for the use of
Internet information services.
This working group is expected to produce a set of documents that
specify standard representations of Uniform Resource Locators
(URLs) for encoding location and
access information across multiple information systems, Unique Resource
Serial Numbers (URSNs) which specify a standardized method for encoding
unique resource identification information for Internet resources, and
Uniform Resource Identifiers (URIs) which specify a standardized
method for encoding combined resource identification and location
information systems to be used for resource discovery and access
systems in an Internet environment. Such standards
are expected to build upon the document discussed at the UDI BOF
session held during the 24th IETF meeting in Boston
Such a set of standards will provide a framework that allows the
Internet user to specify the location and access information for files
and other resources on the Internet, users and network-based
tools to uniquely identify specific resources on the Internet, and
the creation and operation of resource discovery and access
systems for the Internet. The security of such resource discovery
services will also be considered to be an integral part of the work
of this group.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Apr 93 Oct 94 <draft-ietf-uri-url-08.txt>
Uniform Resource Locators (URL)
May 93 Aug 94 <draft-ietf-uri-resource-names-02.txt>
Uniform Resource Names
Mar 94 Oct 94 <draft-ietf-uri-urn-req-01.txt>
Functional 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 Nov 94 <draft-ietf-uri-relative-url-02.txt>
Relative Uniform Resource Locators
Nov 94 New <draft-ietf-uri-urc-req-00.txt>
URC Scenarios and Requirements
Nov 94 New <draft-ietf-uri-url-irp-00.txt>
Uniform Resource Locators for Z39.50
User Services (uswg)
--------------------
Charter
Current status: active working group
Chair(s):
Joyce K. Reynolds <jkrey@isi.edu>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:us-wg@nic.near.net
To Subscribe: us-wg-request@nic.near.net
Archive: ftp.near.net:/mail-archives/us-wg*
Description of Working Group:
The User Services Working Group provides a regular forum for people
interested in user services to identify and initiate projects designed
to improve the quality of information available to end-users of the
Internet. (Note that the actual projects themselves will be handled
by separate groups, such as IETF working groups created to perform certain
projects, or outside organizations such as SIGUCCS.)
(1) Meet on a regular basis to consider projects designed to improve services
to end-users. In general, projects should:
- Clearly address user assistance needs;
- Produce an end-result (e.g., a document, a program plan, etc.);
- Have a reasonably clear approach to achieving the end-result
(with an estimated time for completion); and
- Not duplicate existing or previous efforts.
(2) Create working groups or other focus groups to carry out projects deemed
worthy of pursuing.
(3) Provide a forum in which user services providers can discuss and identify
common concerns.
Internet-Drafts:
No Current Internet-Drafts.
Whois and Network Information Lookup Service (wnils)
----------------------------------------------------
Charter
Current status: active working group
Chair(s):
Joan Gargano <jcgargano@ucdavis.edu>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:ietf-wnils@ucdavis.edu
To Subscribe: ietf-wnils-request@ucdavis.edu
Archive: ucdavis.edu:~/archive/wnils
Description of Working Group:
The Network Information Center maintains the central ``NICNAME''
database and server, defined in RFC 954, providing on-line look-up of
individuals, network organizations, key nodes, and other information
of interest to those who use the Internet. Other distributed
directory information servers and information retrieval tools have
been developed and it is anticipated more will be created. Many sites
now maintain local directory servers with information about
individuals, departments and services at that specific site.
Typically these directory servers are network accessible. Because
these servers are local, there are now wide variations in the type of
data stored, access methods, search schemes, and user interfaces. The
purpose of the Whois and Network Information Lookup Service (WNILS)
Working Group is to expand and define the standard for WHOIS services,
to resolve issues associated with the variations in access and to
promote a consistent and predictable service across the network.
Internet-Drafts:
Posted Revised I-D Title <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