path: root/doc/rfc/rfc3499.txt

Network Working Group                                          S. Ginoza
Request for Comments: 3499                                           ISI
Category: Informational                                    December 2003


                      Request for Comments Summary

                         RFC Numbers 3400-3499

Status of This Memo

   This RFC is a slightly annotated list of the 100 RFCs from RFC 3400
   through RFC 3499.  This is a status report on these RFCs.  This memo
   provides information for the Internet community.  It does not specify
   an Internet standard of any kind.  Distribution of this memo is
   unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Note

   Many RFCs, but not all, are Proposed Standards, Draft Standards, or
   Standards.  Since the status of these RFCs may change during the
   standards processing, we note here only that they are on the
   standards track.  Please see the latest edition of "Internet Official
   Protocol Standards" for the current state and status of these RFCs.
   In the following, RFCs on the standards track are marked [STANDARDS
   TRACK].

RFC     Author          Date            Title
---     ------          ----            -----

3499    Ginoza                          Request for Comments Summary

This memo.














Ginoza                       Informational                      [Page 1]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3498    Kuhfeld         Mar 2003        Definitions of Managed Objects
                                        for Synchronous Optical
                                        Network (SONET) Linear
                                        Automatic Protection Switching
                                        (APS) Architectures

This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP based internets.  In
particular, it defines objects for managing networks using Synchronous
Optical Network (SONET) linear Automatic Protection Switching (APS)
architectures.  [STANDARDS TRACK]


3497    Gharai          Mar 2003        RTP Payload Format for
                                        Society of Motion Picture and
                                        Television Engineers (SMPTE)
                                        292M Video

This memo specifies an RTP payload format for encapsulating uncompressed
High Definition Television (HDTV) as defined by the Society of Motion
Picture and Television Engineers (SMPTE) standard, SMPTE 292M.  SMPTE is
the main standardizing body in the motion imaging industry and the SMPTE
292M standard defines a bit-serial digital interface for local area HDTV
transport.  [STANDARDS TRACK]


3496    Malis           Mar 2003        Protocol Extension for Support
                                        of Asynchronous Transfer Mode
                                        (ATM) Service Class-aware
                                        Multiprotocol Label Switching
                                        (MPLS) Traffic Engineering

This document specifies a Resource ReSerVation Protocol-Traffic
Engineering (RSVP-TE) signaling extension for support of Asynchronous
Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching
(MPLS) Traffic Engineering.  This memo provides information for the
Internet community.














Ginoza                       Informational                      [Page 2]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3495    Beser           Mar 2003        Dynamic Host Configuration
                                        Protocol (DHCP) Option
                                        for CableLabs Client
                                        Configuration

This document defines a Dynamic Host Configuration Protocol (DHCP)
option that will be used to configure various devices deployed within
CableLabs architectures.  Specifically, the document describes DHCP
option content that will be used to configure one class of CableLabs
client device: a PacketCable Media Terminal Adapter (MTA).  The option
content defined within this document will be extended as future
CableLabs client devices are developed.  [STANDARDS TRACK]


3494    Zeilenga        Mar 2003        Lightweight Directory Access
                                        Protocol version 2 (LDAPv2)
                                        to Historic Status

This document recommends the retirement of version 2 of the Lightweight
Directory Access Protocol (LDAPv2) and other dependent specifications,
and discusses the reasons for doing so.  This document recommends RFC
1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded)
be moved to Historic status.  This memo provides information for the
Internet community.


3493    Gilligan        Mar 2003        Basic Socket Interface
                                        Extensions for IPv6

The de facto standard Application Program Interface (API) for TCP/IP
applications is the "sockets" interface.  Although this API was
developed for Unix in the early 1980s it has also been implemented on a
wide variety of non-Unix systems.  TCP/IP applications written using the
sockets API have in the past enjoyed a high degree of portability and we
would like the same portability with IPv6 applications.  But changes are
required to the sockets API to support IPv6 and this memo describes
these changes.  These include a new socket address structure to carry
IPv6 addresses, new address conversion functions, and some new socket
options.  These extensions are designed to provide access to the basic
IPv6 features required by TCP and UDP applications, including
multicasting, while introducing a minimum of change into the system and
providing complete compatibility for existing IPv4 applications.
Additional extensions for advanced IPv6 features (raw sockets and access
to the IPv6 extension headers) are defined in another document.  This
memo provides information for the Internet community.






Ginoza                       Informational                      [Page 3]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3492    Costello        Mar 2003        Punycode: A Bootstring
                                        encoding of Unicode for
                                        Internationalized Domain Names
                                        in Applications (IDNA)

Punycode is a simple and efficient transfer encoding syntax designed for
use with Internationalized Domain Names in Applications (IDNA).  It
uniquely and reversibly transforms a Unicode string into an ASCII
string.  ASCII characters in the Unicode string are represented
literally, and non-ASCII characters are represented by ASCII characters
that are allowed in host name labels (letters, digits, and hyphens).
This document defines a general algorithm called Bootstring that allows
a string of basic code points to uniquely represent any string of code
points drawn from a larger set.  Punycode is an instance of Bootstring
that uses particular parameter values specified by this document,
appropriate for IDNA.  [STANDARDS TRACK]


3491    Hoffman         Mar 2003        Nameprep: A Stringprep Profile
                                        for Internationalized Domain
                                        Names (IDN)

This document describes how to prepare internationalized domain name
(IDN) labels in order to increase the likelihood that name input and
name comparison work in ways that make sense for typical users
throughout the world.  This profile of the stringprep protocol is used
as part of a suite of on-the-wire protocols for internationalizing the
Domain Name System (DNS).  [STANDARDS TRACK]


3490    Faltstrom       Mar 2003        Internationalizing Domain
                                        Names in Applications (IDNA)

Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire.  This document defines
internationalized domain names (IDNs) and a mechanism called
Internationalizing Domain Names in Applications (IDNA) for handling them
in a standard fashion.  IDNs use characters drawn from a large
repertoire (Unicode), but IDNA allows the non-ASCII characters to be
represented using only the ASCII characters already allowed in so-called
host names today.  This backward-compatible representation is required
in existing protocols like DNS, so that IDNs can be introduced with no
changes to the existing infrastructure.  IDNA is only meant for
processing domain names, not free text.  [STANDARDS TRACK]







Ginoza                       Informational                      [Page 4]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3489    Rosenberg       Mar 2003        STUN - Simple Traversal of
                                        User Datagram Protocol (UDP)
                                        Through Network Address
                                        Translators (NATs)

Simple Traversal of User Datagram Protocol (UDP) Through Network Address
Translators (NATs) (STUN) is a lightweight protocol that allows
applications to discover the presence and types of NATs and firewalls
between them and the public Internet.  It also provides the ability for
applications to determine the public Internet Protocol (IP) addresses
allocated to them by the NAT.  STUN works with many existing NATs, and
does not require any special behavior from them.  As a result, it allows
a wide variety of applications to work through existing NAT
infrastructure.  [STANDARDS TRACK]


3488    Wu              Feb 2003        Cisco Systems Router-port
                                        Group Management Protocol
                                        (RGMP)

This document describes the Router-port Group Management Protocol
(RGMP).  This protocol was developed by Cisco Systems and is used
between multicast routers and switches to restrict multicast packet
forwarding in switches to those routers where the packets may be needed.

RGMP is designed for backbone switched networks where multiple, high
speed routers are interconnected.  This memo provides information for
the Internet community.


3487    Schulzrinne     Feb 2003        Requirements for Resource
                                        Priority Mechanisms for the
                                        Session Initiation Protocol
                                        (SIP)

This document summarizes requirements for prioritizing access to
circuit-switched network, end system and proxy resources for emergency
preparedness communications using the Session Initiation Protocol (SIP).
This memo provides information for the Internet community.


3486    Camarillo       Feb 2003        Compressing the Session
                                        Initiation Protocol (SIP)

This document describes a mechanism to signal that compression is
desired for one or more Session Initiation Protocol (SIP) messages.  It
also states when it is appropriate to send compressed SIP messages to a
SIP entity.  [STANDARDS TRACK]



Ginoza                       Informational                      [Page 5]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3485    Garcia-Martin   Feb 2003        The Session Initiation
                                        Protocol (SIP) and Session
                                        Description Protocol
                                        (SDP) Static Dictionary for
                                        Signaling Compression
                                        (SigComp)

The Session Initiation Protocol (SIP) is a text-based protocol for
initiating and managing communication sessions.  The protocol can be
compressed by using Signaling Compression (SigComp).  Similarly, the
Session Description Protocol (SDP) is a text-based protocol intended for
describing multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session initiation.
This memo defines the SIP/SDP-specific static dictionary that SigComp
may use in order to achieve higher efficiency.  The dictionary is
compression algorithm independent.  [STANDARDS TRACK]


3484    Draves          Feb 2003        Default Address Selection for
                                        Internet Protocol version 6
                                        (IPv6)

This document describes two algorithms, for source address selection and
for destination address selection.  The algorithms specify default
behavior for all Internet Protocol version 6 (IPv6) implementations.
They do not override choices made by applications or upper-layer
protocols, nor do they preclude the development of more advanced
mechanisms for address selection.  The two algorithms share a common
context, including an optional mechanism for allowing administrators to
provide policy that can override the default behavior.  In dual stack
implementations, the destination address selection algorithm can
consider both IPv4 and IPv6 addresses - depending on the available
source addresses, the algorithm might prefer IPv6 addresses over IPv4
addresses, or vice-versa.

All IPv6 nodes, including both hosts and routers, must implement default
address selection as defined in this specification.  [STANDARDS TRACK]














Ginoza                       Informational                      [Page 6]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3483    Rawlins         Mar 2003        Framework for Policy Usage
                                        Feedback for Common Open
                                        Policy Service with Policy
                                        Provisioning (COPS-PR)

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the
capability of reporting information to the Policy Decision Point (PDP).
The types of report information are success, failure and accounting of
an installed state.  This document focuses on the COPS Report Type of
Accounting and the necessary framework for the monitoring and reporting
of usage feedback for an installed state.  This memo provides
information for the Internet community.


3482    Foster          Feb 2003        Number Portability in the
                                        Global Switched Telephone
                                        Network (GSTN): An Overview

This document provides an overview of E.164 telephone number portability
(NP) in the Global Switched Telephone Network (GSTN).

NP is a regulatory imperative seeking to liberalize local telephony
service competition, by enabling end-users to retain telephone numbers
while changing service providers.  NP changes the fundamental nature of
a dialed E.164 number from a hierarchical physical routing address to a
virtual address, thereby requiring the transparent translation of the
later to the former.  In addition, there are various regulatory
constraints that establish relevant parameters for NP implementation,
most of which are not network technology specific.  Consequently, the
implementation of NP behavior consistent with applicable regulatory
constraints, as well as the need for interoperation with the existing
GSTN NP implementations, are relevant topics for numerous areas of IP
telephony works-in-progress with the IETF.  This memo provides
information for the Internet community.

















Ginoza                       Informational                      [Page 7]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3481    Inamura, Ed.    Feb 2003        TCP over Second (2.5G)
                                        and Third (3G) Generation
                                        Wireless Networks

This document describes a profile for optimizing TCP to adapt so that it
handles paths including second (2.5G) and third (3G) generation wireless
networks.  It describes the relevant characteristics of 2.5G and 3G
networks, and specific features of example deployments of such networks.
It then recommends TCP algorithm choices for nodes known to be starting
or ending on such paths, and it also discusses open issues.  The
configuration options recommended in this document are commonly found in
modern TCP stacks, and are widely available standards-track mechanisms
that the community considers safe for use on the general Internet.  This
document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.


3480    Kompella        Feb 2003        Signalling Unnumbered Links in
                                        CR-LDP (Constraint-Routing
                                        Label Distribution Protocol)

Current signalling used by Multi-Protocol Label Switching Traffic
Engineering (MPLS TE) does not provide support for unnumbered links.
This document defines procedures and extensions to Constraint-Routing
Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling
protocols that are needed in order to support unnumbered links.
[STANDARDS TRACK]

3479    Farrel, Ed.     Feb 2003        Fault Tolerance for the Label
                                        Distribution Protocol (LDP)

Multiprotocol Label Switching (MPLS) systems will be used in core
networks where system downtime must be kept to an absolute minimum.
Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault
Tolerant (FT) hardware or software to provide high availability of the
core networks.

The details of how FT is achieved for the various components of an FT
LSR, including Label Distribution Protocol (LDP), the switching hardware
and TCP, are implementation specific.  This document identifies issues
in the LDP specification in RFC 3036, "LDP Specification", that make it
difficult to implement an FT LSR using the current LDP protocols, and
defines enhancements to the LDP specification to ease such FT LSR
implementations.







Ginoza                       Informational                      [Page 8]
^L
RFC 3499                  Summary of 3400-3499             December 2003


The issues and extensions described here are equally applicable to RFC
3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).  [STANDARDS
TRACK]


3478    Leelanivas      Feb 2003        Graceful Restart Mechanism for
                                        Label Distribution Protocol

This document describes a mechanism that helps to minimize the negative
effects on MPLS traffic caused by Label Switching Router's (LSR's)
control plane restart, specifically by the restart of its Label
Distribution Protocol (LDP) component, on LSRs that are capable of
preserving the MPLS forwarding component across the restart.

The mechanism described in this document is applicable to all LSRs, both
those with the ability to preserve forwarding state during LDP restart
and those without (although the latter needs to implement only a subset
of the mechanism described in this document).  Supporting (a subset of)
the mechanism described here by the LSRs that can not preserve their
MPLS forwarding state across the restart would not reduce the negative
impact on MPLS traffic caused by their control plane restart, but it
would minimize the impact if their neighbor(s) are capable of preserving
the forwarding state across the restart of their control plane and
implement the mechanism described here.

The mechanism makes minimalistic assumptions on what has to be preserved
across restart - the mechanism assumes that only the actual MPLS
forwarding state has to be preserved; the mechanism does not require any
of the LDP-related states to be preserved across the restart.

The procedures described in this document apply to downstream
unsolicited label distribution.  Extending these procedures to
downstream on demand label distribution is for further study.
[STANDARDS TRACK]


3477    Kompella        Jan 2003        Signalling Unnumbered Links in
                                        Resource ReSerVation Protocol -
                                        Traffic Engineering (RSVP-TE)

Current signalling used by Multi-Protocol Label Switching Traffic
Engineering (MPLS TE) does not provide support for unnumbered links.
This document defines procedures and extensions to Resource ReSerVation
Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of
the MPLS TE signalling protocols, that are needed in order to support
unnumbered links.  [STANDARDS TRACK]





Ginoza                       Informational                      [Page 9]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3476    Rajagopalan     Mar 2003        Documentation of IANA
                                        Assignments for Label
                                        Distribution Protocol
                                        (LDP), Resource ReSerVation
                                        Protocol (RSVP), and Resource
                                        ReSerVation Protocol-Traffic
                                        Engineering (RSVP-TE)
                                        Extensions for Optical UNI
                                        Signaling

The Optical Interworking Forum (OIF) has defined extensions to the Label
Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP)
for optical User Network Interface (UNI) signaling.  These extensions
consist of a set of new data objects and error codes.  This document
describes these extensions.  This memo provides information for the
Internet community.


3475    Aboul-Magd      Mar 2003        Documentation of IANA
                                        assignments for
                                        Constraint-Based LSP setup
                                        using LDP (CR-LDP) Extensions
                                        for Automatic Switched Optical
                                        Network (ASON)

Automatic Switched Optical Network (ASON) is an architecture, specified
by ITU-T Study Group 15, for the introduction of a control plane for
optical networks.  The ASON architecture specifies a set of reference
points that defines the relationship between the ASON architectural
entities.  Signaling over interfaces defined in those reference points
can make use of protocols that are defined by the IETF in the context of
Generalized Multi-Protocol Label Switching (GMPLS) work.  This document
describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for
signaling over the interfaces defined in the ASON reference points.  The
purpose of the document is to request that the IANA assigns code points
necessary for the CR-LDP extensions.  The protocol specifications for
the use of the CR-LDP extensions are found in ITU-T documents.  This
memo provides information for the Internet community.













Ginoza                       Informational                     [Page 10]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3474    Lin             Mar 2003        Documentation of IANA
                                        assignments for Generalized
                                        MultiProtocol Label Switching
                                        (GMPLS) Resource Reservation
                                        Protocol - Traffic Engineering
                                        (RSVP-TE) Usage and Extensions
                                        for Automatically Switched
                                        Optical Network (ASON)

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol
specifications has been defined to provide support for different
technologies as well as different applications.  These include support
for requesting TDM connections based on Synchronous Optical
NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical
Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS suite
of protocols, specifically GMPLS signaling using Resource Reservation
Protocol - Traffic Engineering (RSVP-TE).  It proposes additional
extensions to these signaling protocols to support the capabilities of
an ASON network.

This document proposes appropriate extensions towards the resolution of
additional requirements identified and communicated by the ITU-T Study
Group 15 in support of ITU's ASON standardization effort.  This memo
provides information for the Internet community.


3473    Berger          Jan 2003        Generalized Multi-Protocol
                                        Label Switching (GMPLS)
                                        Signaling Resource ReserVation
                                        Protocol-Traffic Engineering
                                        (RSVP-TE) Extensions

This document describes extensions to Multi-Protocol Label Switching
(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
signaling required to support Generalized MPLS.  Generalized MPLS
extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a RSVP-TE specific description of the extensions.  A generic
functional description can be found in separate documents.  [STANDARDS
TRACK]







Ginoza                       Informational                     [Page 11]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3472    Ashwood-Smith   Jan 2003        Generalized Multi-Protocol
                                        Label Switching (GMPLS)
                                        Signaling Constraint-based
                                        Routed Label Distribution
                                        Protocol (CR-LDP) Extensions

This document describes extensions to Multi-Protocol Label Switching
(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP)
signaling required to support Generalized MPLS.  Generalized MPLS
extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a CR-LDP specific description of the extensions.  A generic
functional description can be found in separate documents.  [STANDARDS
TRACK]


3471    Berger          Jan 2003        Generalized Multi-Protocol
                                        Label Switching (GMPLS)
                                        Signaling Functional
                                        Description

This document describes extensions to Multi-Protocol Label Switching
(MPLS) signaling required to support Generalized MPLS.  Generalized MPLS
extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a functional description of the extensions.  Protocol specific
formats and mechanisms, and technology specific details are specified in
separate documents.  [STANDARDS TRACK]


3470    Hollenbeck      Jan 2003        Guidelines for the Use
                                        of Extensible Markup
                                        Language (XML)
                                        within IETF Protocols

The Extensible Markup Language (XML) is a framework for structuring
data.  While it evolved from Standard Generalized Markup Language (SGML)
-- a markup language primarily focused on structuring documents -- XML
has evolved to be a widely-used mechanism for representing structured
data.







Ginoza                       Informational                     [Page 12]
^L
RFC 3499                  Summary of 3400-3499             December 2003


There are a wide variety of Internet protocols being developed; many
have need for a representation for structured data relevant to their
application.  There has been much interest in the use of XML as a
representation method.  This document describes basic XML concepts,
analyzes various alternatives in the use of XML, and provides guidelines
for the use of XML within IETF standards-track protocols.  This document
specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.


3469    Sharma, Ed.     Feb 2003        Framework for Multi-Protocol
                                        Label Switching (MPLS)-based
                                        Recovery

Multi-protocol label switching (MPLS) integrates the label swapping
forwarding paradigm with network layer routing.  To deliver reliable
service, MPLS requires a set of procedures to provide protection of the
traffic carried on different paths.  This requires that the label
switching routers (LSRs) support fault detection, fault notification,
and fault recovery mechanisms, and that MPLS signaling support the
configuration of recovery.  With these objectives in mind, this document
specifies a framework for MPLS based recovery.  Restart issues are not
included in this framework.  This memo provides information for the
Internet community.


3468    Andersson       Feb 2003        The Multiprotocol Label
                                        Switching (MPLS) Working Group
                                        decision on MPLS signaling
                                        protocols

This document documents the consensus reached by the Multiprotocol Label
Switching (MPLS) Working Group within the IETF to focus its efforts on
"Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-
Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol
for traffic engineering applications and to undertake no new efforts
relating to "Constraint-Based LSP Setup using Label Distribution
Protocol (LDP)" (RFC 3212).  The recommendations of section 6 have been
accepted by the IESG.  This memo provides information for the Internet
community.











Ginoza                       Informational                     [Page 13]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3467    Klensin         Feb 2003        Role of the Domain Name System
                                        (DNS)

This document reviews the original function and purpose of the domain
name system (DNS).  It contrasts that history with some of the purposes
for which the DNS has recently been applied and some of the newer
demands being placed upon it or suggested for it.  A framework for an
alternative to placing these additional stresses on the DNS is then
outlined.  This document and that framework are not a proposed solution,
only a strong suggestion that the time has come to begin thinking more
broadly about the problems we are encountering and possible approaches
to solving them.  This memo provides information for the Internet
community.


3466    Day             Feb 2003        A Model for Content
                                        Internetworking (CDI)

Content (distribution) internetworking (CDI) is the technology for
interconnecting content networks, sometimes previously called "content
peering" or "CDN peering".  A common vocabulary helps the process of
discussing such interconnection and interoperation.  This document
introduces content networks and content internetworking, and defines
elements for such a common vocabulary.  This memo provides information
for the Internet community.


3465    Allman          Feb 2003        TCP Congestion Control with
                                        Appropriate Byte Counting
                                        (ABC)

This document proposes a small modification to the way TCP increases its
congestion window.  Rather than the traditional method of increasing the
congestion window by a constant amount for each arriving acknowledgment,
the document suggests basing the increase on the number of previously
unacknowledged bytes each ACK covers.  This change improves the
performance of TCP, as well as closes a security hole TCP receivers can
use to induce the sender into increasing the sending rate too rapidly.
This memo defines an Experimental Protocol for the Internet community.












Ginoza                       Informational                     [Page 14]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3464    Moore           Jan 2003        An Extensible Message Format
                                        for Delivery Status
                                        Notifications

This memo defines a Multipurpose Internet Mail Extensions (MIME)
content-type that may be used by a message transfer agent (MTA) or
electronic mail gateway to report the result of an attempt to deliver a
message to one or more recipients.  This content-type is intended as a
machine-processable replacement for the various types of delivery status
notifications currently used in Internet electronic mail.

Because many messages are sent between the Internet and other messaging
systems (such as X.400 or the so-called "Local Area Network (LAN)-based"
systems), the Delivery Status Notification (DSN) protocol is designed to
be useful in a multi-protocol messaging environment.  To this end, the
protocol described in this memo provides for the carriage of "foreign"
addresses and error codes, in addition to those normally used in
Internet mail.  Additional attributes may also be defined to support
"tunneling" of foreign notifications through Internet mail.  [STANDARDS
TRACK]


3463    Vaudreuil       Jan 2003        Enhanced Mail System Status
                                        Codes

This document defines a set of extended status codes for use within the
mail system for delivery status reports, tracking, and improved
diagnostics.  In combination with other information provided in the
Delivery Status Notification (DSN) delivery report, these codes
facilitate media and language independent rendering of message delivery
status.  [STANDARDS TRACK]


3462    Vaudreuil       Jan 2003        The Multipart/Report Content
                                        Type for the Reporting of
                                        Mail System Administrative
                                        Messages

The Multipart/Report Multipurpose Internet Mail Extensions (MIME)
content-type is a general "family" or "container" type for electronic
mail reports of any kind.  Although this memo defines only the use of
the Multipart/Report content-type with respect to delivery status
reports, mail processing programs will benefit if a single content-type
is used to for all kinds of reports.







Ginoza                       Informational                     [Page 15]
^L
RFC 3499                  Summary of 3400-3499             December 2003


This document is part of a four document set describing the delivery
status report service.  This collection includes the Simple Mail
Transfer Protocol (SMTP) extensions to request delivery status reports,
a MIME content for the reporting of delivery reports, an enumeration of
extended status codes, and a multipart container for the delivery
report, the original message, and a human-friendly summary of the
failure.  [STANDARDS TRACK]


3461    Moore           Jan 2003        Simple Mail Transfer Protocol
                                        (SMTP) Service Extension
                                        for Delivery Status
                                        Notifications (DSNs)

This memo defines an extension to the Simple Mail Transfer Protocol
(SMTP) service, which allows an SMTP client to specify (a) that Delivery
Status Notifications (DSNs) should be generated under certain
conditions, (b) whether such notifications should return the contents of
the message, and (c) additional information, to be returned with a DSN,
that allows the sender to identify both the recipient(s) for which the
DSN was issued, and the transaction in which the original message was
sent.  [STANDARDS TRACK]


3460    Moore           Jan 2003        Policy Core Information Model
                                        (PCIM) Extensions

This document specifies a number of changes to the Policy Core
Information Model (PCIM, RFC 3060).  Two types of changes are included.
First, several completely new elements are introduced, for example,
classes for header filtering, that extend PCIM into areas that it did
not previously cover.  Second, there are cases where elements of PCIM
(for example, policy rule priorities) are deprecated, and replacement
elements are defined (in this case, priorities tied to associations that
refer to policy rules).  Both types of changes are done in such a way
that, to the extent possible, interoperability with implementations of
the original PCIM model is preserved.  This document updates RFC 3060.
[STANDARDS TRACK]


3459    Burger          Jan 2003        Critical Content Multi-purpose
                                        Internet Mail Extensions
                                        (MIME) Parameter

This document describes the use of a mechanism for identifying body
parts that a sender deems critical in a multi-part Internet mail
message.  The mechanism described is a parameter to Content-Disposition,
as described by RFC 3204.



Ginoza                       Informational                     [Page 16]
^L
RFC 3499                  Summary of 3400-3499             December 2003


By knowing what parts of a message the sender deems critical, a content
gateway can intelligently handle multi-part messages when providing
gateway services to systems of lesser capability.  Critical content can
help a content gateway to decide what parts to forward.  It can indicate
how hard a gateway should try to  deliver a body part.  It can help the
gateway to pick body parts that are safe to silently delete when a
system of lesser capability receives a message.  In addition, critical
content can help the gateway chose the notification strategy for the
receiving system.  Likewise, if the sender expects the destination to do
some processing on a body part, critical content allows the sender to
mark body parts that the receiver must process.  [STANDARDS TRACK]


3458    Burger          Jan 2003        Message Context for Internet
                                        Mail

This memo describes a new RFC 2822 message header, "Message-Context".
This header provides information about the context and presentation
characteristics of a message.

A receiving user agent (UA) may use this information as a hint to
optimally present the message.  [STANDARDS TRACK]


3457    Kelly           Jan 2003        Requirements for IPsec Remote
                                        Access Scenarios

IPsec offers much promise as a secure remote access mechanism.  However,
there are a number of differing remote access scenarios, each having
some shared and some unique requirements.  A thorough understanding of
these requirements is necessary in order to effectively evaluate the
suitability of a specific set of mechanisms for any particular remote
access scenario.  This document enumerates the requirements for a number
of common remote access scenarios.  This memo provides information for
the Internet community.
















Ginoza                       Informational                     [Page 17]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3456    Patel           Jan 2003        Dynamic Host Configuration
                                        Protocol (DHCPv4)
                                        Configuration of IPsec Tunnel
                                        Mode

This memo explores the requirements for host configuration in IPsec
tunnel mode, and describes how the Dynamic Host Configuration Protocol
(DHCPv4) may be leveraged for configuration.  In many remote access
scenarios, a mechanism for making the remote host appear to be present
on the local corporate network is quite useful.  This may be
accomplished by assigning the host a "virtual" address from the
corporate network, and then tunneling traffic via IPsec from the host's
ISP-assigned address to the corporate security gateway.  In IPv4, DHCP
provides for such remote host configuration.  [STANDARDS TRACK]


3455    Garcia-Martin   Jan 2003        Private Header (P-Header)
                                        Extensions to the Session
                                        Initiation Protocol (SIP) for
                                        the 3rd-Generation Partnership
                                        Project (3GPP)

This document describes a set of private Session Initiation Protocol
(SIP) headers (P-headers) used by the 3rd-Generation Partnership Project
(3GPP), along with their applicability, which is limited to particular
environments.  The P-headers are for a variety of purposes within the
networks that the partners use, including charging and information about
the networks a call traverses.  This memo provides information for the
Internet community.


3454    Hoffman         Dec 2002        Preparation of
                                        Internationalized Strings
                                        ("stringprep")

This document describes a framework for preparing Unicode text strings
in order to increase the likelihood that string input and string
comparison work in ways that make sense for typical users throughout the
world.  The stringprep protocol is useful for protocol identifier
values, company and personal names, internationalized domain names, and
other text strings.

This document does not specify how protocols should prepare text
strings.  Protocols must create profiles of stringprep in order to fully
specify the processing options.  [STANDARDS TRACK]






Ginoza                       Informational                     [Page 18]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3453    Luby            Dec 2002        The Use of Forward Error
                                        Correction (FEC) in Reliable
                                        Multicast

This memo describes the use of Forward Error Correction (FEC) codes to
efficiently provide and/or augment reliability for one-to-many reliable
data transport using IP multicast.  One of the key properties of FEC
codes in this context is the ability to use the same packets containing
FEC data to simultaneously repair different packet loss patterns at
multiple receivers.  Different classes of FEC codes and some of their
basic properties are described and terminology relevant to implementing
FEC in a reliable multicast protocol is introduced.  Examples are
provided of possible abstract formats for packets carrying FEC.  This
memo provides information for the Internet community.


3452    Luby            Dec 2002        Forward Error Correction (FEC)
                                        Building Block

This document generally describes how to use Forward Error Correction
(FEC) codes to efficiently provide and/or augment reliability for data
transport.  The primary focus of this document is the application of FEC
codes to one-to-many reliable data transport using IP multicast.  This
document describes what information is needed to identify a specific FEC
code, what information needs to be communicated out-of-band to use the
FEC code, and what information is needed in data packets to identify the
encoding symbols they carry.  The procedures for specifying FEC codes
and registering them with the Internet Assigned Numbers Authority (IANA)
are also described.  This document should be read in conjunction with
and uses the terminology of the companion document titled, "The Use of
Forward Error Correction (FEC) in Reliable Multicast".  This memo
defines an Experimental Protocol for the Internet community.


3451    Luby            Dec 2002        Layered Coding Transport (LCT)
                                        Building Block

Layered Coding Transport (LCT) provides transport level support for
reliable content delivery and stream delivery protocols.  LCT is
specifically designed to support protocols using IP multicast, but also
provides support to protocols that use unicast.  LCT is compatible with
congestion control that provides multiple rate delivery to receivers and
is also compatible with coding techniques that provide reliable delivery
of content.  This memo defines an Experimental Protocol for the Internet
community.






Ginoza                       Informational                     [Page 19]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3450    Luby            Dec 2002        Asynchronous Layered Coding
                                        (ALC) Protocol Instantiation

This document describes the Asynchronous Layered Coding (ALC) protocol,
a massively scalable reliable content delivery protocol.  Asynchronous
Layered Coding combines the Layered Coding Transport (LCT) building
block, a multiple rate congestion control building block and the Forward
Error Correction (FEC) building block to provide congestion controlled
reliable asynchronous delivery of content to an unlimited number of
concurrent receivers from a single sender.  This memo defines an
Experimental Protocol for the Internet community.


3449    Balakrishnan    Dec 2002        TCP Performance Implications
                                        of Network Path Asymmetry

This document describes TCP performance problems that arise because of
asymmetric effects.  These problems arise in several access networks,
including bandwidth-asymmetric networks and packet radio subnetworks,
for different underlying reasons.  However, the end result on TCP
performance is the same in both cases: performance often degrades
significantly because of imperfection and variability in the ACK
feedback from the receiver to the sender.

The document details several mitigations to these effects, which have
either been proposed or evaluated in the literature, or are currently
deployed in networks.  These solutions use a combination of local link-
layer techniques, subnetwork, and end-to-end mechanisms, consisting of:
(i) techniques to manage the channel used for the upstream bottleneck
link carrying the ACKs, typically using header compression or reducing
the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK
frequency to retain the TCP sender's acknowledgment-triggered self-
clocking and (iii) techniques to schedule the data and ACK packets in
the reverse direction to improve performance in the presence of two-way
traffic.  Each technique is described, together with known issues, and
recommendations for use.  A summary of the recommendations is provided
at the end of the document.  This document specifies an Internet Best
Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.












Ginoza                       Informational                     [Page 20]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3448    Handley         Jan 2003        TCP Friendly Rate Control
                                        (TFRC): Protocol Specification

This document specifies TCP-Friendly Rate Control (TFRC).  TFRC is a
congestion control mechanism for unicast flows operating in a best-
effort Internet environment.  It is reasonably fair when competing for
bandwidth with TCP flows, but has a much lower variation of throughput
over time compared with TCP, making it more suitable for applications
such as telephony or streaming media where a relatively smooth sending
rate is of importance.  [STANDARDS TRACK]


3447    Jonsson         Feb 2003        Public-Key Cryptography
                                        Standards (PKCS) #1: RSA
                                        Cryptography Specifications
                                        Version 2.1

This memo represents a republication of PKCS #1 v2.1 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process.  The body of this
document is taken directly from the PKCS #1 v2.1 document, with certain
corrections made during the publication process.  This memo provides
information for the Internet community.


3446    Kim             Jan 2003        Anycast Rendevous Point (RP)
                                        mechanism using Protocol
                                        Independent Multicast (PIM)
                                        and Multicast Source Discovery
                                        Protocol (MSDP)


This document describes a mechanism to allow for an arbitrary number of
Rendevous Points (RPs) per group in a single shared-tree Protocol
Independent Multicast-Sparse Mode (PIM-SM) domain.  This memo provides
information for the Internet community.















Ginoza                       Informational                     [Page 21]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3445    Massey          Dec 2002        Limiting the Scope of the KEY
                                        Resource Record (RR)

This document limits the Domain Name System (DNS) KEY Resource Record
(RR) to only keys used by the Domain Name System Security Extensions
(DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC keys
and arbitrary application keys.  Storing both DNSSEC and application
keys with the same record type is a mistake.  This document removes
application keys from the KEY record by redefining the Protocol Octet
field in the KEY RR Data.  As a result of removing application keys, all
but one of the flags in the KEY record become unnecessary and are
redefined.  Three existing application key sub-types are changed to
reserved, but the format of the KEY record is not changed.  This
document updates RFC 2535.  [STANDARDS TRACK]


3444    Pras            Jan 2003        On the Difference between
                                        Information Models and Data
                                        Models

There has been ongoing confusion about the differences between
Information Models and Data Models for defining managed objects in
network management.  This document explains the differences between
these terms by analyzing how existing network management model
specifications (from the IETF and other bodies such as the International
Telecommunication Union (ITU) or the Distributed Management Task Force
(DMTF)) fit into the universe of Information Models and Data Models.

This memo documents the main results of the 8th workshop of the Network
Management Research Group (NMRG) of the Internet Research Task Force
(IRTF) hosted by the University of Texas at Austin.  This memo provides
information for the Internet community.


3443    Agarwal         Jan 2003        Time To Live (TTL) Processing
                                        in Multi-Protocol Label
                                        Switching (MPLS) Networks

This document describes Time To Live (TTL) processing in hierarchical
Multi-Protocol Label Switching (MPLS) networks and is motivated by the
need to formalize a TTL-transparent mode of operation for an MPLS
label-switched path.  It updates RFC 3032, "MPLS Label Stack Encoding".
TTL processing in both Pipe and Uniform Model hierarchical tunnels are
specified with examples for both "push" and "pop" cases.  The document
also complements RFC 3270, "MPLS Support of Differentiated Services" and
ties together the terminology introduced in that document with TTL
processing in hierarchical MPLS networks.  [STANDARDS TRACK]




Ginoza                       Informational                     [Page 22]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3442    Lemon           Dec 2002        The Classless Static Route
                                        Option for Dynamic Host
                                        Configuration Protocol (DHCP)
                                        version 4

This document defines a new Dynamic Host Configuration Protocol (DHCP)
option which is passed from the DHCP Server to the DHCP Client to
configure a list of static routes in the client.  The network
destinations in these routes are classless - each routing table entry
includes a subnet mask.  [STANDARDS TRACK]


3441    Kumar           Jan 03          Asynchronous Transfer Mode
                                        (ATM) Package for the Media
                                        Gateway Control Protocol
                                        (MGCP)

This document describes an Asynchronous Transfer Mode (ATM) package for
the Media Gateway Control Protocol (MGCP).  This package includes new
Local Connection Options, ATM-specific events and signals, and ATM
connection parameters.  Also included is a description of codec and
profile negotiation.  It extends the MGCP that is currently being
deployed in a number of products.  Implementers should be aware of
developments in the IETF Megaco Working Group and ITU SG16, which are
currently working on a potential successor to this protocol.  This memo
provides information for the Internet community.


3440    Ly              Dec 2002        Definitions of Extension
                                        Managed Objects for Asymmetric
                                        Digital Subscriber Lines

This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.  In
particular, it describes additional managed objects used for managing
Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the
ADSL Line MIB (RFC 2662).  [STANDARDS TRACK]














Ginoza                       Informational                     [Page 23]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3439    Bush            Dec 2002        Some Internet Architectural
                                        Guidelines and Philosophy

This document extends RFC 1958 by outlining some of the philosophical
guidelines to which architects and designers of Internet backbone
networks should adhere.  We describe the Simplicity Principle, which
states that complexity is the primary mechanism that impedes efficient
scaling, and discuss its implications on the architecture, design and
engineering issues found in large scale Internet backbones.  This memo
provides information for the Internet community.


3438    Townsley        Dec 2002        Layer Two Tunneling Protocol
                                        (L2TP) Internet Assigned
                                        Numbers Authority (IANA)
                                        Considerations Update

This document describes updates to the Internet Assigned Numbers
Authority (IANA) considerations for the Layer Two Tunneling Protocol
(L2TP).  This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions for
improvements.


3437    Palter          Dec 2002        Layer-Two Tunneling Protocol
                                        Extensions for PPP Link
                                        Control Protocol Negotiation

This document defines extensions to the Layer Two Tunneling Protocol
(L2TP) for enhanced support of link-specific Point to Point Protocol
(PPP) options.  PPP endpoints typically have direct access to the common
physical media connecting them and thus have detailed knowledge about
the media that is in use.  When the L2TP is used, the two PPP peers are
no longer directly connected over the same physical media.  Instead,
L2TP inserts a virtual connection over some or all of the PPP connection
by tunneling PPP frames over a packet switched network such as IP.
Under some conditions, an L2TP endpoint may need to negotiate PPP Link
Control Protocol (LCP) options at a location which may not have access
to all of the media information necessary for proper participation in
the LCP negotiation.  This document provides a mechanism for
communicating desired LCP options between L2TP endpoints in advance of
PPP LCP negotiation at the far end of an L2TP tunnel, as well as a
mechanism for communicating the negotiated LCP options back to where the
native PPP link resides.  [STANDARDS TRACK]







Ginoza                       Informational                     [Page 24]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3436    Jungmaier       Dec 2002        Transport Layer Security over
                                        Stream Control Transmission
                                        Protocol

This document describes the usage of the Transport Layer Security (TLS)
protocol, as defined in RFC 2246, over the Stream Control Transmission
Protocol (SCTP), as defined in RFC 2960 and RFC 3309.

The user of TLS can take advantage of the features provided by SCTP,
namely the support of multiple streams to avoid head of line blocking
and the support of multi-homing to provide network level fault
tolerance.

Additionally, discussions of extensions of SCTP are also supported,
meaning especially the support of dynamic reconfiguration of IP-
addresses.  [STANDARDS TRACK]


3435    Andreasen       Jan 03          Media Gateway Control Protocol
                                        (MGCP) Version 1.0


This document describes an application programming interface and a
corresponding protocol (MGCP) which is used between elements of a
decomposed multimedia gateway.  The decomposed multimedia gateway
consists of a Call Agent, which contains the call control
"intelligence", and a media gateway which contains the media functions,
e.g., conversion from TDM voice to Voice over IP.

Media gateways contain endpoints on which the Call Agent can create,
modify and delete connections in order to establish and control media
sessions with other multimedia endpoints.  Also, the Call Agent can
instruct the endpoints to detect certain events and generate signals.
The endpoints automatically communicate changes in service state to the
Call Agent.  Furthermore, the Call Agent can audit endpoints as well as
the connections on endpoints.

The basic and general MGCP protocol is defined in this document, however
most media gateways will need to implement one or more MGCP packages,
which define extensions to the protocol suitable for use with specific
types of media gateways.  Such packages are defined in separate
documents.  This memo provides information for the Internet community.









Ginoza                       Informational                     [Page 25]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3434    Bierman         Dec 2002        Remote Monitoring MIB
                                        Extensions for High Capacity
                                        Alarms

This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.  In
particular, it describes managed objects for extending the alarm
thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC
2819), to provide similar threshold monitoring of objects based on the
Counter64 data type.  [STANDARDS TRACK]


3433    Bierman         Dec 2002        Entity Sensor Management
                                        Information Base

This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.  In
particular, it describes managed objects for extending the Entity MIB
(RFC 2737) to provide generalized access to information related to
physical sensors, which are often found in networking equipment (such as
chassis temperature, fan RPM, power supply voltage).  [STANDARDS TRACK]


3432    Raisanen        Nov 2002        Network performance
                                        measurement with periodic
                                        streams

This memo describes a periodic sampling method and relevant metrics for
assessing the performance of IP networks.  First, the memo motivates
periodic sampling and addresses the question of its value as an
alternative to the Poisson sampling described in RFC 2330.  The benefits
include applicability to active and passive measurements, simulation of
constant bit rate (CBR) traffic (typical of multimedia communication, or
nearly CBR, as found with voice activity detection), and several
instances in which analysis can be simplified.  The sampling method
avoids predictability by mandating random start times and finite length
tests.  Following descriptions of the sampling method and sample metric
parameters, measurement methods and errors are discussed.  Finally, we
give additional information on periodic measurements, including security
considerations.  [STANDARDS TRACK]











Ginoza                       Informational                     [Page 26]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3431    Segmuller       Dec 2002        Sieve Extension: Relational
                                        Tests

This document describes the RELATIONAL extension to the Sieve mail
filtering language defined in RFC 3028.  This extension extends existing
conditional tests in Sieve to allow relational operators.  In addition
to testing their content, it also allows for testing of the number of
entities in header and envelope fields.  [STANDARDS TRACK]


3430    Schoenwaelder   Dec 2002        Simple Network Management
                                        Protocol (SNMP) over
                                        Transmission Control Protocol
                                        (TCP) Transport Mapping

This memo defines a transport mapping for using the Simple Network
Management Protocol (SNMP) over TCP.  The transport mapping can be used
with any version of SNMP.  This document extends the transport mappings
defined in STD 62, RFC 3417.  This memo defines an Experimental Protocol
for the Internet community.


3429    Ohta            Nov 2002        Assignment of the 'OAM Alert
                                        Label' forMultiprotocol Label
                                        Switching Architecture (MPLS)
                                        Operation and Maintenance
                                        (OAM) Functions

This document describes the assignment of one of the reserved label
values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation
and Maintenance (OAM) Alert Label' that is used by user-plane
Multiprotocol Label Switching Architecture (MPLS) OAM functions for
identification of MPLS OAM packets.  This memo provides information for
the Internet community.


3428    Campbell        Dec 2002        Session Initiation Protocol
                                        (SIP) Extension for Instant
                                        Messaging

Instant Messaging (IM) refers to the transfer of messages between users
in near real-time.  These messages are usually, but not required to be,
short.  IMs are often used in a conversational mode, that is, the
transfer of messages back and forth is fast enough for participants to
maintain an interactive conversation.






Ginoza                       Informational                     [Page 27]
^L
RFC 3499                  Summary of 3400-3499             December 2003


This document proposes the MESSAGE method, an extension to the Session
Initiation Protocol (SIP) that allows the transfer of Instant Messages.
Since the MESSAGE request is an extension to SIP, it inherits all the
request routing and security features of that protocol.  MESSAGE
requests carry the content in the form of MIME body parts.  MESSAGE
requests do not themselves initiate a SIP dialog; under normal usage
each Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some other
SIP request.  [STANDARDS TRACK]


3427    Mankin          Dec 2002        Change Process for the Session
                                        Initiation Protocol (SIP)

This memo documents a process intended to apply architectural discipline
to the future development of the Session Initiation Protocol (SIP).
There have been concerns with regards to new SIP proposals.
Specifically, that the addition of new SIP features can be damaging
towards security and/or greatly increase the complexity of the protocol.
The Transport Area directors, along with the SIP and Session Initiation
Proposal Investigation (SIPPING) working group chairs, have provided
suggestions for SIP modifications and extensions.  This document
specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.


3426    Floyd           Nov 2002        General Architectural and
                                        Policy Considerations

This document suggests general architectural and policy questions that
the IETF community has to address when working on new standards and
protocols.  We note that this document contains questions to be
addressed, as opposed to guidelines or architectural principles to be
followed.  This memo provides information for the Internet community.


3425    Lawrence        Nov 2002        Obsoleting IQUERY

The IQUERY method of performing inverse DNS lookups, specified in RFC
1035, has not been generally implemented and has usually been
operationally disabled where it has been implemented.  Both reflect a
general view in the community that the concept was unwise and that the
widely-used alternate approach of using pointer (PTR) queries and
reverse-mapping records is preferable.  Consequently, this document
deprecates the IQUERY operation, declaring it entirely obsolete.  This
document updates RFC 1035.  [STANDARDS TRACK]





Ginoza                       Informational                     [Page 28]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3424    Daigle          Nov 2002        IAB Considerations for
                                        UNilateral Self-Address Fixing
                                        (UNSAF) Across Network Address
                                        Translation

As a result of the nature of Network Address Translation (NAT)
Middleboxes, communicating endpoints that are separated by one or more
NATs do not know how to refer to themselves using addresses that are
valid in the addressing realms of their (current and future) peers.
Various proposals have been made for "UNilateral Self-Address Fixing
(UNSAF)" processes.  These are processes whereby some originating
endpoint attempts to determine or fix the address (and port) by which it
is known to another endpoint - e.g., to be able to use address data in
the protocol exchange, or to advertise a public address from which it
will receive connections.

This document outlines the reasons for which these proposals can be
considered at best as short term fixes to specific problems and the
specific issues to be carefully evaluated before creating an UNSAF
proposal.  This memo provides information for the Internet community.


3423    Zhang           Nov 2002        XACCT's Common Reliable
                                        Accounting for Network Element
                                        (CRANE) Protocol Specification
                                        Version 1.0

This document defines the Common Reliable Accounting for Network Element
(CRANE) protocol that enables efficient and reliable delivery of any
data, mainly accounting data from Network Elements to any systems, such
as mediation systems and Business Support Systems (BSS)/ Operations
Support Systems (OSS).  The protocol is developed to address the
critical needs for exporting high volume of accounting data from NE's
with efficient use of network, storage, and processing resources.

This document specifies the architecture of the protocol and the message
format, which MUST be supported by all CRANE protocol implementations.
This memo provides information for the Internet community.













Ginoza                       Informational                     [Page 29]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3422    Okamoto         Nov 2002        Forwarding Media Access
                                        Control (MAC) Frames over
                                        Multiple Access Protocol over
                                        Synchronous Optical
                                        Network/Synchronous Digital
                                        Hierarchy (MAPOS)

This memo describes a method for forwarding media access control (MAC)
frames over Multiple Access Protocol over Synchronous Optical
Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to
unify MAPOS network environment and MAC-based Local Area Network (LAN)
environment.  This memo provides information for the Internet community.


3421    Zhao            Nov 2002        Select and Sort Extensions for
                                        the Service Location Protocol
                                        (SLP)

This document defines two extensions (Select and Sort) for the Service
Location Protocol (SLP).  These extensions allow a User Agent (UA) to
request that the Uniform Resource Locator (URL) entries in a Service
Reply (SrvRply) be limited to the specified number, or be sorted
according to the specified sort key list.  Using these two extensions
together can facilitate discovering the best match, such as finding a
service that has the maximum speed or the minimum load.  This memo
defines an Experimental Protocol for the Internet community.


3420    Sparks          Nov 2002        Internet Media Type
                                        message/sipfrag

This document registers the message/sipfrag Multipurpose Internet Mail
Extensions (MIME) media type.  This type is similar to message/sip, but
allows certain subsets of well formed Session Initiation Protocol (SIP)
messages to be represented instead of requiring a complete SIP message.
In addition to end-to-end security uses, message/sipfrag is used with
the REFER method to convey information about the status of a referenced
request.  [STANDARDS TRACK]













Ginoza                       Informational                     [Page 30]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3419    Daniele         Dec 2002        Textual Conventions for
                                        Transport Addresses

This document introduces a Management Information Base (MIB) module that
defines textual conventions to represent commonly used transport-layer
addressing information.  The definitions are compatible with the concept
of TAddress/TDomain pairs introduced by the Structure of Management
Information version 2 (SMIv2) and support the Internet transport
protocols over IPv4 and IPv6.  [STANDARDS TRACK]


3418    Presuhn         Dec 2002        Management Information Base
                                        (MIB) for the Simple Network
                                        Management Protocol (SNMP)


This document defines managed objects which describe the behavior of a
Simple Network Management Protocol (SNMP) entity.  This document
obsoletes RFC 1907, Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2).  [STANDARDS TRACK]


3417    Presuhn         Dec 2002        Transport Mappings for
                                        the Simple Network Management
                                        Protocol (SNMP)

This document defines the transport of Simple Network Management
Protocol (SNMP) messages over various protocols.  This document
obsoletes RFC 1906.  [STANDARDS TRACK]


3416    Presuhn         Dec 2002        Version 2 of the Protocol
                                        Operations for the Simple
                                        Network Management Protocol
                                        (SNMP)

This document defines version 2 of the protocol operations for the
Simple Network Management Protocol (SNMP).  It defines the syntax and
elements of procedure for sending, receiving, and processing SNMP PDUs.
This document obsoletes RFC 1905.  [STANDARDS TRACK]











Ginoza                       Informational                     [Page 31]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3415    Wijnen          Dec 2002        View-based Access Control
                                        Model (VACM) for the
                                        Simple Network Management
                                        Protocol (SNMP)

This document describes the View-based Access Control Model (VACM) for
use in the Simple Network Management Protocol (SNMP) architecture.  It
defines the Elements of Procedure for controlling access to management
information.  This document also includes a Management Information Base
(MIB) for remotely managing the configuration parameters for the View-
based Access Control Model.  This document obsoletes RFC 2575.
[STANDARDS TRACK]


3414    Blumenthal      Dec 2002        User-based Security Model
                                        (USM) for version 3 of the
                                        Simple Network Management
                                        Protocol (SNMPv3)

This document describes the User-based Security Model (USM) for Simple
Network Management Protocol (SNMP) version 3 for use in the SNMP
architecture.  It defines the Elements of Procedure for providing SNMP
message level security.  This document also includes a Management
Information Base (MIB) for remotely monitoring/managing the
configuration parameters for this Security Model.  This document
obsoletes RFC 2574.  [STANDARDS TRACK]


3413    Levi            Dec 2002        Simple Network Management
                                        Protocol (SNMP) Applications

This document describes five types of Simple Network Management Protocol
(SNMP) applications which make use of an SNMP engine as described in STD
62, RFC 3411.  The types of application described are Command
Generators, Command Responders, Notification Originators, Notification
Receivers, and Proxy Forwarders.

This document also defines Management Information Base (MIB) modules for
specifying targets of management operations, for notification filtering,
and for proxy forwarding.  This document obsoletes RFC 2573.  [STANDARDS
TRACK]










Ginoza                       Informational                     [Page 32]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3412    Case            Dec 2002        Message Processing and
                                        Dispatching for the Simple
                                        Network Management Protocol
                                        (SNMP)

This document describes the Message Processing and Dispatching for
Simple Network Management Protocol (SNMP) messages within the SNMP
architecture.  It defines the procedures for dispatching potentially
multiple versions of SNMP messages to the proper SNMP Message Processing
Models, and for dispatching PDUs to SNMP applications.  This document
also describes one Message Processing Model - the SNMPv3 Message
Processing Model.  This document obsoletes RFC 2572. [STANDARDS TRACK]


3411    Harrington      Dec 2002        An Architecture for Describing
                                        Simple Network Management
                                        Protocol (SNMP) Management
                                        Frameworks

This document describes an architecture for describing Simple Network
Management Protocol (SNMP) Management Frameworks.  The architecture is
designed to be modular to allow the evolution of the SNMP protocol
standards over time.  The major portions of the architecture are an SNMP
engine containing a Message Processing Subsystem, a Security Subsystem
and an Access Control Subsystem, and possibly multiple SNMP applications
which provide specific functional processing of management data.  This
document obsoletes RFC 2571.  [STANDARDS TRACK]


3410    Case            Dec 2002        Introduction and Applicability
                                        Statements for Internet
                                        Standard Management Framework

The purpose of this document is to provide an overview of the third
version of the Internet-Standard Management Framework, termed the SNMP
version 3 Framework (SNMPv3).  This Framework is derived from and builds
upon both the original Internet-Standard Management Framework (SNMPv1)
and the second Internet-Standard Management Framework (SNMPv2).

The architecture is designed to be modular to allow the evolution of the
Framework over time.

The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is
strongly recommended.  The document also recommends that RFCs 1157,
1441, 1901, 1909 and 1910 be retired by moving them to Historic status.
This document obsoletes RFC 2570.  This memo provides information for
the Internet community.




Ginoza                       Informational                     [Page 33]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3409    Svanbro          Dec 2002       Lower Layer Guidelines for
                                        Robust RTP/UDP/IP Header
                                        Compression

This document describes lower layer guidelines for robust header
compression (ROHC) and the requirements ROHC puts on lower layers.  The
purpose of this document is to support the incorporation of robust
header compression algorithms, as specified in the ROHC working group,
into different systems such as those specified by Third Generation
Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical
Standards Institute (ETSI), etc.  This document covers only lower layer
guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified
in [RFC3095].  Both general guidelines and guidelines specific for
cellular systems are discussed in this document.  This memo provides
information for the Internet community.


3408    Liu             Dec 2002        Zero-byte Support for
                                        Bidirectional Reliable Mode
                                        (R-mode) in Extended
                                        Link-Layer Assisted RObust
                                        Header Compression (ROHC)
                                        Profile

This document defines an additional mode of the link-layer assisted
RObust Header Compression (ROHC) profile, also known as the zero-byte
profile, beyond the two defined in RFC 3242.  Zero-byte header
compression exists in order to prevent the single-octet ROHC header from
pushing a packet voice stream into the next higher fixed packet size for
the radio.  It is usable in certain widely deployed older air
interfaces.  This document adds the zero-byte operation for ROHC
Bidirectional Reliable mode (R-mode) to the ones specified for
Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of
header compression in RFC 3242.  [STANDARDS TRACK]


3407    Andreasen       Oct 2002        Session Description Protocol
                                        (SDP) Simple Capability
                                        Declaration

This document defines a set of Session Description Protocol (SDP)
attributes that enables SDP to provide a minimal and backwards
compatible capability declaration mechanism.  Such capability
declarations can be used as input to a subsequent session negotiation,
which is done by means outside the scope of this document.  This
provides a simple and limited solution to the general capability
negotiation problem being addressed by the next generation of SDP, also
known as SDPng.  [STANDARDS TRACK]



Ginoza                       Informational                     [Page 34]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3406    Daigle          Oct 2002        Uniform Resource Names (URN)
                                        Namespace Definition
                                        Mechanisms

This document lays out general definitions of and mechanisms for
establishing Uniform Resource Names (URN) "namespaces".  The URN WG has
defined a syntax for URNs in RFC 2141, as well as some proposed
mechanisms for their resolution and use in Internet applications in RFC
3401 and RFC 3405.  The whole rests on the concept of individual
"namespaces" within the URN structure.  Apart from proof-of-concept
namespaces, the use of existing identifiers in URNs has been discussed
in RFC 2288.  This document specifies an Internet Best Current Practices
for the Internet Community, and requests discussion and suggestions for
improvements.


3405    Mealling        Oct 2002        Dynamic Delegation Discovery
                                        System (DDDS) Part Five:
                                        URI.ARPA Assignment Procedures

This document is fifth in a series that is completely specified in
"Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive
DDDS" (RFC 3401).  It is very important to note that it is impossible to
read and understand any document in this series without reading the
others.  This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions for
improvements.


3404    Mealling        Oct 2002        Dynamic Delegation Discovery
                                        System (DDDS) Part Four: The
                                        Uniform Resource Identifiers
                                        (URI) Resolution Application

This document describes a specification for taking Uniform Resource
Identifiers (URI) and locating an authoritative server for information
about that URI.  The method used to locate that authoritative server is
the Dynamic Delegation Discovery System.

This document is part of a series that is specified in "Dynamic
Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"
(RFC 3401).  It is very important to note that it is impossible to read
and understand any document in this series without reading the others.
[STANDARDS TRACK]







Ginoza                       Informational                     [Page 35]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3403    Mealling        Oct 2002        Dynamic Delegation Discovery
                                        System (DDDS) Part Three: The
                                        Domain Name System (DNS)
                                        Database

This document describes a Dynamic Delegation Discovery System (DDDS)
Database using the Domain Name System (DNS) as a distributed database of
Rules.  The Keys are domain-names and the Rules are encoded using the
Naming Authority Pointer (NAPTR) Resource Record (RR).

Since this document obsoletes RFC 2915, it is the official specification
for the NAPTR DNS Resource Record.  It is also part of a series that is
completely specified in "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS" (RFC 3401).  It is very important to note
that it is impossible to read and understand any document in this series
without reading the others.  [STANDARDS TRACK]


3402    Mealling        Oct 2002        Dynamic Delegation Discovery
                                        System (DDDS) Part Two: The
                                        Algorithm

This document describes the Dynamic Delegation Discovery System (DDDS)
algorithm for applying dynamically retrieved string transformation rules
to an application-unique string.  Well-formed transformation rules will
reflect the delegation of management of information associated with the
string.  This document is also part of a series that is completely
specified in "Dynamic Delegation Discovery System (DDDS) Part One: The
Comprehensive DDDS" (RFC 3401).  It is very important to note that it is
impossible to read and understand any document in this series without
reading the others.  [STANDARDS TRACK]


3401    Mealling        Oct 2002        Dynamic Delegation Discovery
                                        System (DDDS) Part One: The
                                        Comprehensive DDDS

This document specifies the exact documents that make up the complete
Dynamic Delegation Discovery System (DDDS).  DDDS is an abstract
algorithm for applying dynamically retrieved string transformation rules
to an application-unique string.  This document along with RFC 3402, RFC
3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC
2276.  This memo provides information for the Internet community.








Ginoza                       Informational                     [Page 36]
^L
RFC 3499                  Summary of 3400-3499             December 2003


3400                                    Never Issued

RFC 3400 was never issued.


Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Sandy Ginoza
   University of Southern California
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone:  (310) 822-1511
   EMail: ginoza@isi.edu
































Ginoza                       Informational                     [Page 37]
^L
RFC 3499                  Summary of 3400-3499             December 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ginoza                       Informational                     [Page 38]
^L