Movatterモバイル変換

Network Working Group                                          S. GinozaRequest for Comments: 3299                                           ISICategory: Informational                                    December 2003Request for Comments Summary                         RFC Numbers 3200-3299Status of This Memo   This RFC is a slightly annotated list of the 100 RFCs fromRFC 3200   throughRFC 3299.  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---     ------          ----            -----3299    Ginoza        Dec 2003        Request for Comments SummaryThis memo.Ginoza                       Informational                      [Page 1]

RFC 3299                  Summary of 3200-3299             December 20033298    Faynberg      Aug 2002        Service in the Public Switched                                        Telephone Network/Intelligent                                        Network (PSTN/IN) Requesting                                        InTernet Service (SPIRITS)                                        Protocol RequirementsThis document describes the SPIRITS protocol requirements, based on thearchitecture presented inRFC 3136.  (SPIRITS stands for "Service in thePSTN/IN Requesting InTernet Service".)  The purpose of the protocol isto support services that originate in the Public Switched TelephoneNetwork (PSTN) and necessitate the interactions between the PSTN and theInternet.  Similarly, such services are called SPIRITS services.(Internet Call Waiting, Internet Caller-ID Delivery, and Internet CallForwarding are examples of SPIRIT services, but the protocol is todefine the building blocks from which many other services can be built.)On the PSTN side, the SPIRITS services are initiated from theIntelligent Network (IN) entities; the earlier IETF work on thePSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) insupport of the services initiated the other way around--from theInternet to PSTN.To this end, this document lists general requirements for the SPIRITSprotocol as well as those pertinent to IN, Wireless IN, and PINTbuilding blocks.  The document also presents the SPIRITS WG consensus onthe choice of the SPIRITS signaling protocol.  This memo providesinformation for the Internet community.3297    Klyne         Jul 2002        Content Negotiation for                                        Messaging Services based on                                        EmailThis memo describes a content negotiation mechanism for facsimile, voiceand other messaging services that use Internet email.  [STANDARDS TRACK]3296    Zeilenga      Jul 2002        Named Subordinate References                                        in Lightweight Directory                                        Access Protocol (LDAP)                                        DirectoriesThis document details schema and protocol elements for representing andmanaging named subordinate references in Lightweight Directory AccessProtocol (LDAP) Directories.  [STANDARDS TRACK]Ginoza                       Informational                      [Page 2]

RFC 3299                  Summary of 3200-3299             December 20033295    Sjostrand     Jun 2002        Definitions of Managed Objects                                        for the General Switch                                        Management Protocol (GSMP)This memo defines a portion of the Management Information Base (MIB) forthe use with the network management protocols in the Internet community.In particular, it describes managed objects for the General SwitchManagement Protocol (GSMP).  [STANDARDS TRACK]3294    Doria         Jun 2002        General Switch Management                                        Protocol (GSMP) ApplicabilityThis memo provides an overview of the GSMP (General Switch ManagementProtocol) and includes information relating to its deployment in a IPnetwork in an MPLS environment.  It does not discuss deployment in anATM (Asynchronous Transfer Mode) network or in a raw ethernetconfiguration.  This memo provides information for the Internetcommunity.3293    Doria         Jun 2002        General Switch Management                                        Protocol (GSMP) Packet                                        Encapsulations for                                        Asynchronous Transfer Mode                                        (ATM), Ethernet and                                        Transmission Control Protocol                                        (TCP)This memo specifies the encapsulation of GSMP (General Switch ManagementProtocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP(Transmission Control Protocol).  [STANDARDS TRACK]3292    Doria         Jun 2002        General Switch Management                                        Protocol (GSMP) V3This document describes the General Switch Management Protocol Version 3(GSMPv3).  The GSMPv3 is an asymmetric protocol that allows one or moreexternal switch controllers to establish and maintain the state of alabel switch such as, an ATM, frame relay or MPLS switch.  The GSMPv3allows control of both unicast and multicast switch connection state aswell as control of switch system resources and QoS features.  [STANDARDSTRACK]Ginoza                       Informational                      [Page 3]

RFC 3299                  Summary of 3200-3299             December 20033291    Daniele       May 2002        Textual Conventions for                                        Internet Network AddressesThis MIB module defines textual conventions to represent commonly usedInternet network layer addressing information.  The intent is that thesetextual conventions (TCs) will be imported and used in MIB modules thatwould otherwise define their own representations.  [STANDARDS TRACK]3290    Bernet        May 2002        An Informal Management Model                                        for Diffserv RoutersThis document proposes an informal management model of DifferentiatedServices (Diffserv) routers for use in their management andconfiguration.  This model defines functional datapath elements (e.g.,classifiers, meters, actions, marking, absolute dropping, counting,multiplexing), algorithmic droppers, queues and schedulers.  Itdescribes possible configuration parameters for these elements and howthey might be interconnected to realize the range of trafficconditioning and per-hop behavior (PHB) functionalities described in theDiffserv Architecture.  This memo provides information for the Internetcommunity.3289    Baker         May 2002        Management Information Base                                        for the Differentiated                                        Services ArchitectureThis memo describes an SMIv2 (Structure of Management Informationversion 2) MIB for a device implementing the Differentiated ServicesArchitecture.  It may be used both for monitoring and configuration of arouter or switch capable of Differentiated Services functionality.[STANDARDS TRACK]3288    O'Tuathail    Jun 2002        Using the Simple Object Access                                        Protocol (SOAP) in Blocks                                        Extensible Exchange Protocol                                        (BEEP)This memo specifies a Simple Object Access Protocol (SOAP) binding tothe Blocks Extensible Exchange Protocol core (BEEP).  A SOAP bindingdescribes how SOAP messages are transmitted in the network.  [STANDARDSTRACK]Ginoza                       Informational                      [Page 4]

RFC 3299                  Summary of 3200-3299             December 20033287    Bierman       Jul 2002        Remote Monitoring MIB                                        Extensions for                                        Differentiated ServicesThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community.  Inparticular, it describes managed objects used for monitoringDifferentiated Services (DS) Codepoint usage in packets which contain aDS field, utilizing the monitoring framework defined in the RMON-2(Remote Network Monitoring Management Version 2) MIB.  [STANDARDS TRACK]3286    Ong           May 2002        An Introduction to the Stream                                        Control Transmission Protocol                                        (SCTP)This document provides a high level introduction to the capabilitiessupported by the Stream Control Transmission Protocol (SCTP).  It isintended as a guide for potential users of SCTP as a general purposetransport protocol.  This memo provides information for the Internetcommunity.3285    Gahrns        May 2002        Using Microsoft Word to create                                        Internet Drafts and RFCsThis document describes the steps to configure the Microsoft Wordapplication to produce documents in Internet Draft and RFC format.  Thismemo provides information for the Internet community.3284    Korn          Jun 2002        The VCDIFF Generic                                        Differencing and Compression                                        Data FormatThis memo describes VCDIFF, a general, efficient and portable dataformat suitable for encoding compressed and/or differencing data so thatthey can be easily transported among computers.  [STANDARDS TRACK]Ginoza                       Informational                      [Page 5]

RFC 3299                  Summary of 3200-3299             December 20033283    Mahoney       Jun 2002        Guide to Internet CalendaringThis document describes the various Internet calendaring and schedulingstandards and works in progress, and the relationships between them.Its intent is to provide a context for these documents, assist in theirunderstanding, and potentially aid in the design of standards-basedcalendaring and scheduling systems.  The standards addressed are RFC2445 (iCalendar),RFC 2446 (iTIP), andRFC 2447 (iMIP).The work inprogress addressed is "Calendar Access Protocol" (CAP).  This documentalso describes issues and problems that are not solved by theseprotocols, and that could be targets for future work.  This memoprovides information for the Internet community.3282    Alvestrand    May 2002        Content Language HeadersThis document defines a "Content-language:" header, for use in caseswhere one desires to indicate the language of something that has RFC822-like headers, like MIME body parts or Web documents, and an"Accept-Language:" header for use in cases where one wishes to indicateone's preferences with regard to language.  [STANDARDS TRACK]3281    Farrell       Apr 2002        An Internet Attribute                                        Certificate Profile for                                        AuthorizationThis specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols.  Attribute certificates may be usedin a wide range of applications and environments covering a broadspectrum of interoperability goals and a broader spectrum of operationaland assurance requirements.  The goal of this document is to establish acommon baseline for generic applications requiring broadinteroperability as well as limited special purpose requirements.  Theprofile places emphasis on attribute certificate support for Internetelectronic mail, IPSec, and WWW security applications.  [STANDARDSTRACK]3280    Housley       Apr 2002        Internet X.509 Public Key                                        Infrastructure Certificate and                                        Certificate Revocation List                                        (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 CertificateRevocation List (CRL) for use in the Internet.  [STANDARDS TRACK]Ginoza                       Informational                      [Page 6]

RFC 3299                  Summary of 3200-3299             December 20033279    Polk          Apr 2002        Algorithms and Identifiers for                                        the Internet X.509 Public Key                                        Infrastructure Certificate and                                        Certificate Revocation List                                        (CRL) ProfileThis document specifies algorithm identifiers and ASN.1 encoding formatsfor digital signatures and subject public keys used in the InternetX.509 Public Key Infrastructure (PKI).  Digital signatures are used tosign certificates and certificate revocation list (CRLs).  Certificatesinclude the public key of the named subject.  [STANDARDS TRACK]3278    Blake-Wilson  Apr 2002        Use of Elliptic Curve                                        Cryptography (ECC) Algorithms                                        in Cryptographic Message                                        Syntax (CMS)This document describes how to use Elliptic Curve Cryptography (ECC)public-key algorithms in the Cryptographic Message Syntax (CMS).  TheECC algorithms support the creation of digital signatures and theexchange of keys to encrypt or authenticate content.  The definition ofthe algorithm processing is based on the ANSI X9.62 standard, developedby the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1standard.  This memo provides information for the Internet community.3277    McPherson     Apr 2002        Intermediate System to                                        Intermediate System (IS-IS)                                        Transient Blackhole AvoidanceThis document describes a simple, interoperable mechanism that can beemployed in Intermediate System to Intermediate System (IS-IS) networksin order to decrease the data loss associated with deterministicblackholing of packets during transient network conditions.  Themechanism proposed here requires no IS-IS protocol changes and iscompletely interoperable with the existing IS-IS specification.  Thismemo provides information for the Internet community.Ginoza                       Informational                      [Page 7]

RFC 3299                  Summary of 3200-3299             December 20033276    Ray           May 2002        Definitions of Managed Objects                                        for High Bit-Rate DSL - 2nd                                        generation (HDSL2) and                                        Single-Pair High-Speed Digital                                        Subscriber Line (SHDSL) LinesThis document defines a portion of the Management Information Base (MIB)module for use with network management protocols in the Internetcommunity.  In particular, it describes objects used for managing HighBit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed DigitalSubscriber Line (SHDSL) interfaces.  [STANDARDS TRACK]3275    Eastlake 3rd  Mar 2002        (Extensible Markup Language)                                        XML-Signature Syntax and                                        ProcessingThis document specifies XML (Extensible Markup Language) digitalsignature processing rules and syntax.  [STANDARDS TRACK]3274    Gutmann       Jun 2002        Compressed Data Content Type                                        for Cryptographic Message                                        Syntax (CMS)This document defines a format for using compressed data as aCryptographic Message Syntax (CMS) content type.  Compressing databefore transmission provides a number of advantages, including theelimination of data redundancy which could help an attacker, speeding upprocessing by reducing the amount of data to be processed by later steps(such as signing or encryption), and reducing overall message size.Although there have been proposals for adding compression at otherlevels (for example at the MIME or SSL level), these don't address theproblem of compression of CMS content unless the compression is suppliedby an external means (for example by intermixing MIME and CMS).[STANDARDS TRACK]Ginoza                       Informational                      [Page 8]

RFC 3299                  Summary of 3200-3299             December 20033273    Waldbusser    Jul 2002        Remote Network Monitoring                                        Management Information Base                                        for High Capacity NetworksThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in TCP/IP-based internets.  Inparticular, it defines objects for managing remote network monitoring(RMON) devices for use on high speed networks.  This document contains aMIB Module that defines these new objects and also contains definitionsof some updated objects from the RMON-MIB inRFC 2819 and the RMON2-MIBinRFC 2021.  [PROPOSED STANDARD]3272    Awduche       May 2002        Overview and Principles of                                        Internet Traffic EngineeringThis memo describes the principles of Traffic Engineering (TE) in theInternet.  The document is intended to promote better understanding ofthe issues surrounding traffic engineering in IP networks, and toprovide a common basis for the development of traffic engineeringcapabilities for the Internet.  The principles, architectures, andmethodologies for performance evaluation and performance optimization ofoperational IP networks are discussed throughout this document.  Thismemo provides information for the Internet community.3271    Cerf          Apr 2002        The Internet is for EveryoneThis document expresses the Internet Society's ideology that theInternet really is for everyone.  However, it will only be such  if wemake it so.  This memo provides information for the Internet community.3270    Le Faucheur   May 2002        Multi-Protocol Label Switching                                        (MPLS) Support of                                        Differentiated ServicesThis document defines a flexible solution for support of DifferentiatedServices (Diff-Serv) over Multi-Protocol Label Switching (MPLS)networks.  [STANDARDS TRACK]Ginoza                       Informational                      [Page 9]

RFC 3299                  Summary of 3200-3299             December 20033269    Kermode       Apr 2002        Author Guidelines for Reliable                                        Multicast Transport (RMT)                                        Building Blocks and Protocol                                        Instantiation documentsThis document provides general guidelines to assist the authors ofReliable Multicast Transport (RMT) building block and protocolinstantiation definitions.  The purpose of these guidelines is to ensurethat any building block and protocol instantiation definitions producedcontain sufficient information to fully explain their operation and use.In addition these guidelines provide directions to specify modular andclearly defined RMT building blocks and protocol instantiations that canbe refined and augmented to safely create new protocols for use in newscenarios for which any existing protocols were not designed.  This memoprovides information for the Internet community.3268    Chown         Jun 2002        Advanced Encryption Standard                                        (AES) Ciphersuites for                                        Transport Layer Security (TLS)This document proposes several new ciphersuites.  At present, thesymmetric ciphers supported by Transport Layer Security (TLS) are RC2,RC4, International Data Encryption Algorithm (IDEA), Data EncryptionStandard (DES), and triple DES.  The protocol would be enhanced by theaddition of Advanced Encryption Standard (AES) ciphersuites.  [STANDARDSTRACK]3267    Sjoberg       Jun 2002        Real-Time Transport Protocol                                        (RTP) Payload Format and File                                        Storage Format for the                                        Adaptive Multi-Rate (AMR) and                                        Adaptive Multi-Rate Wideband                                        (AMR-WB) Audio CodecsThis document specifies a real-time transport protocol (RTP) payloadformat to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-RateWideband (AMR-WB) encoded speech signals.  The payload format isdesigned to be able to interoperate with existing AMR and AMR-WBtransport formats on non-IP networks.  In addition, a file format isspecified for transport of AMR and AMR-WB speech data in storage modeapplications such as email.  Two separate MIME type registrations areincluded, one for AMR and one for AMR-WB, specifying use of both the RTPpayload format and the storage format.  [STANDARDS TRACK]Ginoza                       Informational                     [Page 10]

RFC 3299                  Summary of 3200-3299             December 20033266    Olson         Jun 2002        Support for IPv6 in Session                                        Description Protocol (SDP)This document describes the use of Internet Protocol Version 6 (IPv6)addresses in conjunction with the Session Description Protocol (SDP).Specifically, this document clarifies existing text in SDP with regardsto the syntax of IPv6 addresses.  [STANDARDS TRACK]3265    Roach         Jun 2002        Session Initiation Protocol                                        (SIP)-Specific Event                                        NotificationThis document describes an extension to the Session Initiation Protocol(SIP).  The purpose of this extension is to provide an extensibleframework by which SIP nodes can request notification from remote nodesindicating that certain events have occurred.  [STANDARDS TRACK]3264    Rosenberg     Jun 2002        An Offer/Answer Model with the                                        Session Description Protocol                                        (SDP)This document defines a mechanism by which two entities can make use ofthe Session Description Protocol (SDP) to arrive at a common view of amultimedia session between them.  In the model, one participant offersthe other a description of the desired session from their perspective,and the other participant answers with the desired session from theirperspective.  This offer/answer model is most useful in unicast sessionswhere information from both participants is needed for the complete viewof the session.  The offer/answer model is used by protocols like theSession Initiation Protocol (SIP).  [STANDARDS TRACK]3263    Rosenberg     Jun 2002        Session Initiation Protocol                                        (SIP): Locating SIP ServersThe Session Initiation Protocol (SIP) uses DNS procedures to allow aclient to resolve a SIP Uniform Resource Identifier (URI) into the IPaddress, port, and transport protocol of the next hop to contact.  Italso uses DNS to allow a server to send a response to a backup client ifthe primary client has failed.  This document describes those DNSprocedures in detail.  [STANDARDS TRACK]Ginoza                       Informational                     [Page 11]

RFC 3299                  Summary of 3200-3299             December 20033262    Rosenberg     Jun 2002        Reliability of Provisional                                        Responses in the Session                                        Initiation Protocol (SIP)This document specifies an extension to the Session Initiation Protocol(SIP) providing reliable provisional response messages.  This extensionuses the option tag 100rel and defines the Provisional ResponseACKnowledgement (PRACK) method.  [STANDARDS TRACK]3261    Rosenberg     Jun 2002        SIP: Session Initiation                                        ProtocolThis document describes Session Initiation Protocol (SIP), anapplication-layer control (signaling) protocol for creating, modifying,and terminating sessions with one or more participants.  These sessionsinclude Internet telephone calls, multimedia distribution, andmultimedia conferences.  [STANDARDS TRACK]3260    Grossman      Apr 2002        New Terminology and                                        Clarifications for DiffservThis memo captures Diffserv working group agreements concerning new andimproved terminology, and provides minor technical clarifications.  Itis intended to updateRFC 2474,RFC 2475 andRFC 2597.  When RFCs 2474and 2597 advance on the standards track, andRFC 2475 is updated, it isintended that the revisions in this memo will be incorporated, and thatthis memo will be obsoleted by the new RFCs.  This memo providesinformation for the Internet community.3259    Ott           Apr 2002        A Message Bus for Local                                        CoordinationThe local Message Bus (Mbus) is a light-weight message-orientedcoordination protocol for group communication between applicationcomponents.  The Mbus provides automatic location of communicationpeers, subject based addressing, reliable message transfer and differenttypes of communication schemes.  The protocol is layered on top of IPmulticast and is specified for IPv4 and IPv6.  The IP multicast scope islimited to link-local multicast.  This document specifies the Mbusprotocol, i.e., message syntax, addressing and transport mechanisms.This memo provides information for the Internet community.Ginoza                       Informational                     [Page 12]

RFC 3299                  Summary of 3200-3299             December 20033258    Hardie        Apr 2002        Distributing Authoritative                                        Name Servers via Shared                                        Unicast AddressesThis memo describes a set of practices intended to enable anauthoritative name server operator to provide access to a single namedserver in multiple locations.  The primary motivation for thedevelopment and deployment of these practices is to increase thedistribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNSquery responses in those areas.  This memo provides information for theInternet community.3257    Coene         Apr 2002        Stream Control Transmission                                        Protocol Applicability                                        StatementThis document describes the applicability of the Stream ControlTransmission Protocol (SCTP).  It also contrasts SCTP with the twodominant transport protocols, User Datagram Protocol (UDP) &Transmission Control Protocol (TCP), and gives some guidelines for whenbest to use SCTP and when not best to use SCTP.  This memo providesinformation for the Internet community.3256    Jones         Apr 2002        The DOCSIS (Data-Over-Cable                                        Service Interface                                        Specifications) Device Class                                        DHCP (Dynamic Host                                        Configuration Protocol) Relay                                        Agent Information Sub-optionThis document proposes a new sub-option to the DHCP (Dynamic HostConfiguration Protocol) Relay Agent Information Option.  [STANDARDSTRACK]Ginoza                       Informational                     [Page 13]

RFC 3299                  Summary of 3200-3299             December 20033255    Jones         Apr 2002        Extending Point-to-Point                                        Protocol (PPP) over                                        Synchronous Optical                                        NETwork/Synchronous Digital                                        Hierarchy (SONET/SDH) with                                        virtual concatenation, high                                        order and low order payloadsThis document describes an extension to the mapping of Point-to-PointProtocol (PPP) into Synchronous Optical NETwork/Synchronous DigitalHierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtualconcatenation and the use of both high order and low order payloads.[STANDARDS TRACK]3254    Alvestrand    Apr 2002        Definitions for talking about                                        directoriesWhen discussing systems for making information accessible through theInternet in standardized ways, it may be useful if the people who arediscussing it have a common understanding of the terms they use.  Forexample, a reference to this document would give one the power to agreethat the DNS (Domain Name System) is a global lookup repository withperimeter integrity and loose, converging consistency.  On the otherhand, a LDAP (Lightweight Directory Access Protocol) directory server isa local, centralized repository with both lookup and search capability.This document discusses one group of such systems which is known underthe term, "directories".  This memo provides information for theInternet community.3253    Clemm         Mar 2002        Versioning Extensions to                                        WebDAV (Web Distributed                                        Authoring and Versioning)This document specifies a set of methods, headers, and resource typesthat define the WebDAV (Web Distributed Authoring and Versioning)versioning extensions to the HTTP/1.1 protocol.  [STANDARDS TRACK]3252    Kennedy       1 April 2002    Binary Lexical Octet Ad-hoc                                        TransportThis document defines a reformulation of IP and two transport layerprotocols (TCP and UDP) as XML applications.  This memo providesinformation for the Internet community.Ginoza                       Informational                     [Page 14]

RFC 3299                  Summary of 3200-3299             December 20033251    Rajagopalan   1 April 2002    Electricity over IPMostly Pointless Lamp Switching (MPLampS) is an architecture forcarrying electricity over IP (with an MPLS control plane).  According toour marketing department, MPLampS has the potential to dramaticallylower the price, ease the distribution and usage, and improve themanageability of delivering electricity.  This document is motivated bysuch work as SONET/SDH over IP/MPLS (with apologies to the authors).Readers of the previous work have been observed scratching their headsand muttering, "What next?".  This document answers that question.  Thismemo provides information for the Internet community.3250    McIntyre      Sep 2002        Tag Image File Format Fax                                        eXtended (TIFF-FX) -                                        image/tiff-fx MIME Sub-type                                        RegistrationThis document describes the registration of the MIME sub-typeimage/tiff-fx.  The encodings are defined by File Format for InternetFax and its extensions.  [STANDARDS TRACK]3249    Cancio        Sep 2002        Implementers Guide for                                        Facsimile Using Internet MailThis document is intended for the implementers of software that useemail to send to facsimiles usingRFC 2305 and 2532.  This is aninformational document and its guidelines do not supersede thereferenced documents.  This memo provides information for the Internetcommunity.Ginoza                       Informational                     [Page 15]

RFC 3299                  Summary of 3200-3299             December 20033248    Armitage      Mar 2002        A Delay Bound alternative                                        revision ofRFC 2598For historical interest, this document captures the EF Design Team'sproposed solution, preferred by the original authors ofRFC 2598 but notadopted by the working group in December 2000.  The original definitionof EF was based on comparison of forwarding on an unloaded network.This experimental Delay Bound (DB) PHB requires a bound on the delay ofpackets due to other traffic in the network.  At the Pittsburgh IETFmeeting in August 2000, the Differentiated Services working group facedserious questions regardingRFC 2598 - the group's standards trackdefinition of the Expedited Forwarding (EF) Per Hop Behavior (PHB).  An'EF Design Team' volunteered to develop a re-expression ofRFC 2598,bearing in mind the issues raised in the DiffServ group.  At the SanDiego IETF meeting in December 2000 the DiffServ working group decidedto pursue an alternative re-expression of the EF PHB.  This memoprovides information for the Internet community.3247    Charny        Mar 2002        Supplemental Information for                                        the New Definition of the EF                                        PHB (Expedited Forwarding                                        Per-Hop Behavior)This document was written during the process of clarification ofRFC2598"An Expedited Forwarding PHB" that led to the publication of revisedspecification of EF "An Expedited Forwarding PHB".  Its primarymotivation is providing additional explanation to the revised EFdefinition and its properties.  The document also provides additionalimplementation examples and gives some guidance for computation of thenumerical parameters of the new definition for several well knownschedulers and router architectures.  This memo provides information forthe Internet community.3246    Davie         Mar 2002        An Expedited Forwarding PHB                                        (Per-Hop Behavior)This document defines a PHB (per-hop behavior) called ExpeditedForwarding (EF).  The PHB is a basic building block in theDifferentiated Services architecture.  EF is intended to provide abuilding block for low delay, low jitter and low loss services byensuring that the EF aggregate is served at a certain configured rate.This document obsoletesRFC 2598.  [STANDARDS TRACK]Ginoza                       Informational                     [Page 16]

RFC 3299                  Summary of 3200-3299             December 20033245    Klensin, Ed.  Mar 2002        The History and Context of                                        Telephone Number Mapping                                        (ENUM) Operational Decisions:                                        Informational Documents                                        Contributed to ITU-T Study                                        Group 2 (SG2)RFC 2916 assigned responsibility for a number of administrative andoperational details of Telephone Number Mapping (ENUM) to the IAB.  Italso anticipated that ITU would take responsibility for determining thelegitimacy and appropriateness of applicants for delegation of "countrycode"-level subdomains of the top-level ENUM domain.  Recently, threememos have been prepared for the ITU-T Study Group 2 (SG2) to explainthe background of, and reasoning for, the relevant decisions.  The IABhas also supplied a set of procedural instructions to the RIPE NCC forimplementation of their part of the model.  The content of the threememos is provided in this document for the information of the IETFcommunity.3244    Swift         Feb 2002        Microsoft Windows 2000                                        Kerberos Change Password and                                        Set Password ProtocolsThis memo specifies Microsoft's Windows 2000 Kerberos change passwordand set password protocols.  The Windows 2000 Kerberos change passwordprotocol interoperates with the original Kerberos change passwordprotocol.  Change password is a request reply protocol that includes aKRB_PRIV message that contains the new password for the user.  This memoprovides information for the Internet community.3243    Jonsson       Apr 2002        RObust Header Compression                                        (ROHC): Requirements and                                        Assumptions for 0-byte                                        IP/UDP/RTP CompressionThis document contains requirements for the 0-byte IP/UDP/RTP (InternetProtocol/User Datagram Protocol/Real-Time Transport Protocol) headercompression scheme to be developed by the Robust Header Compression(ROHC) Working Group.  It also includes the basic assumptions for thetypical link layers over which 0-byte compression may be implemented,and assumptions about its usage in general.Ginoza                       Informational                     [Page 17]

RFC 3299                  Summary of 3200-3299             December 20033242    Jonsson       Apr 2002        RObust Header Compression                                        (ROHC): A Link-Layer Assisted                                        Profile for IP/UDP/RTPThis document defines a ROHC (Robust Header Compression) profile forcompression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionalityprovided by the lower layers to increase compression efficiency bycompletely eliminating the header for most packets during optimaloperation.  The profile is built as an extension to the ROHC RTPprofile.  It defines additional mechanisms needed in ROHC, statesrequirements on the assisting layer to guarantee transparency, andspecifies general logic for compression and decompression making use ofthis header-free packet.  [STANDARDS TRACK]3241    Bormann       Apr 2002        Robust Header Compression                                        (ROHC) over PPPThis document describes an option for negotiating the use of robustheader compression (ROHC) on IP datagrams transmitted over the Point-to-Point Protocol (PPP).  It defines extensions to the PPP ControlProtocols for IPv4 and IPv6.  [STANDARDS TRACK]3240    Clunie        Feb 2002        Digital Imaging and                                        Communications in Medicine                                        (DICOM) - Application/dicom                                        MIME Sub-type RegistrationThis document describes the registration of the MIME sub-typeapplication/dicom (Digital Imaging and Communications in Medicine).  Thebaseline encoding is defined by the DICOM Standards Committee in"Digital Imaging and Communications in Medicine".  This memo providesinformation for the Internet community.Ginoza                       Informational                     [Page 18]

RFC 3299                  Summary of 3200-3299             December 20033239    Kugler        Feb 2002        Internet Printing Protocol                                        (IPP): Requirements for Job,                                        Printer, and Device                                        Administrative OperationsThis document specifies the requirements and uses cases for someoptional administrative operations for use with the Internet PrintingProtocol (IPP) version 1.0 and version 1.1.  Some of theseadministrative operations operate on the IPP Job and Printer objects.The remaining operations operate on a new Device object that moreclosely models a single output device.  This memo provides informationfor the Internet community.3238    IAB           Jan 2002        IAB Architectural and Policy                                        Considerations for Open                                        Pluggable Edge ServicesThis document includes comments and recommendations by the IAB on somearchitectural and policy issues related to the chartering of OpenPluggable Edge Services (OPES) in the IETF.  OPES are services thatwould be deployed at application-level intermediaries in the network,for example, at a web proxy cache between the origin server and theclient.  These intermediaries would transform or filter content, withthe explicit consent of either the content provider or the end user.This memo provides information for the Internet community.3237    Tuexen        Jan 2002        Requirements for Reliable                                        Server PoolingThis document defines a basic set of requirements for reliable serverpooling.  This memo provides information for the Internet community.3236    Baker         Feb 2002        The 'application/xhtml+xml'                                        Media TypeThis document defines the 'application/xhtml+xml' MIME media type forXHTML based markup languages; it is not intended to obsolete anyprevious IETF documents, in particularRFC 2854 which registers'text/html'.  This memo provides information for the Internet community.Ginoza                       Informational                     [Page 19]

RFC 3299                  Summary of 3200-3299             December 20033235    Senie         Jan 2002        Network Address Translator                                        (NAT)-Friendly Application                                        Design GuidelinesThis document discusses those things that application designers mightwish to consider when designing new protocols.  While many commonInternet applications will operate cleanly in the presence of NetworkAddress Translators, others suffer from a variety of problems whencrossing these devices.  Guidelines are presented herein to help ensurenew protocols and applications will, to the extent possible, becompatible with NAT (Network Address Translation).  This memo providesinformation for the Internet community.3234    Carpenter     Feb 2002        Middleboxes: Taxonomy and                                        IssuesThis document is intended as part of an IETF discussion about"middleboxes" - defined as any intermediary box performing functionsapart from normal, standard functions of an IP router on the data pathbetween a source host and destination host.  This document establishes acatalogue or taxonomy of middleboxes, cites previous and current IETFwork concerning middleboxes, and attempts to identify some preliminaryconclusions.  It does not, however, claim to be definitive.  This memoprovides information for the Internet community.3233    Hoffman       Feb 2002        Defining the IETFThis document gives a more concrete definition of "the IETF" as itunderstood today.  Many RFCs refer to "the IETF".  Many important IETFdocuments speak of the IETF as if it were an already-defined entity.However, no IETF document correctly defines what the IETF is.  Thisdocument specifies an Internet Best Current Practices for the InternetCommunity, and requests discussion and suggestions for improvements.3232    Reynolds      Jan 2002        Assigned Numbers:RFC 1700 is                                        Replaced by an On-line DatabaseThis memo obsoletesRFC 1700 (STD 2) "Assigned Numbers", which containedan October 1994 snapshot of assigned Internet protocol parameters.  Thismemo provides information for the Internet community.Ginoza                       Informational                     [Page 20]

RFC 3299                  Summary of 3200-3299             December 20033231    Levi          Jan 2002        Definitions of Managed Objects                                        for Scheduling Management                                        OperationsThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community.  Inparticular, it describes a set of managed objects that are used toschedule management operations periodically or at specified dates andtimes.  [STANDARDS TRACK]3230    Mogul         Jan 2002        Instance Digests in HTTPHTTP/1.1 defines a Content-MD5 header that allows a server to include adigest of the response body.  However, this is specifically defined tocover the body of the actual message, not the contents of the full file(which might be quite different, if the response is a Content-Range, oruses a delta encoding).  Also, the Content-MD5 is limited to onespecific digest algorithm; other algorithms, such as SHA-1 (Secure HashStandard), may be more appropriate in some circumstances.  Finally,HTTP/1.1 provides no explicit mechanism by which a client may request adigest.  This document proposes HTTP extensions that solve theseproblems.  [STANDARDS TRACK]3229    Mogul         Jan 2002        Delta encoding in HTTPThis document describes how delta encoding can be supported as acompatible extension to HTTP/1.1.  [STANDARDS TRACK]3228    Fenner        Feb 2002        IANA Considerations for IPv4                                        Internet Group Management                                        Protocol (IGMP)This memo requests that the IANA create a registry for fields in theIGMP (Internet Group Management Protocol) protocol header, and providesguidance for the IANA to use in assigning parameters for those fields.This document specifies an Internet Best Current Practices for theInternet Community, and requests discussion and suggestions forimprovements.Ginoza                       Informational                     [Page 21]

RFC 3299                  Summary of 3200-3299             December 20033227    Brezinski     Feb 2002        Guidelines for Evidence                                        Collection and ArchivingA "security incident" as defined in the "Internet Security Glossary",RFC 2828, is a security-relevant system event in which the system'ssecurity policy is disobeyed or otherwise breached.  The purpose of thisdocument is to provide System Administrators with guidelines on thecollection and archiving of evidence relevant to such a securityincident.  This document specifies an Internet Best Current Practicesfor the Internet Community, and requests discussion and suggestions forimprovements.3226    Gudmundsson   Dec 2001        DNSSEC and IPv6 A6 aware                                        server/resolver message size                                        requirementsThis document mandates support for EDNS0 (Extension Mechanisms for DNS)in DNS entities claiming to support either DNS Security Extensions or A6records.  This requirement is necessary because these new featuresincrease the size of DNS messages.  If EDNS0 is not supported fall backto TCP will happen, having a detrimental impact on query latency and DNSserver load.  This document updatesRFC 2535 andRFC 2874, by adding newrequirements.  [STANDARDS TRACK]3225    Conrad        Dec 2001        Indicating Resolver Support of                                        DNSSECIn order to deploy DNSSEC (Domain Name System Security Extensions)operationally, DNSSEC aware servers should only perform automaticinclusion of DNSSEC RRs when there is an explicit indication that theresolver can understand those RRs.  This document proposes the use of abit in the EDNS0 header to provide that explicit indication anddescribes the necessary protocol changes to implement that notification.[STANDARDS TRACK]Ginoza                       Informational                     [Page 22]

RFC 3299                  Summary of 3200-3299             December 20033224    Guttman       Jan 2002        Vendor Extensions for Service                                        Location Protocol, Version 2This document specifies how the features of the Service LocationProtocol, Version 2 allow for vendor extensibility safely, with nopossibility of collisions.  The specification introduces a new SLPv2extension:  The Vendor Opaque Extension.  While proprietary protocolextensions are not encouraged by IETF standards, it is important thatthey not hinder interoperability of compliant implementations when theyare undertaken.  This document udpatesRFC 2608, "The Service LocationProtocol."  [STANDARDS TRACK]3223                                    Never IssuedRFC 3223 was never issued.3222    Trotter       Dec 2001        Terminology for Forwarding                                        Information Base (FIB) based                                        Router PerformanceThis document describes the terms to be used in a methodology thatdetermines the IP packet forwarding performance of IP routers as afunction of the forwarding information base installed within a router.The forwarding performance of an IP router may be dependent upon or maybe linked to the composition and size of the forwarding information baseinstalled within a router.  This memo provides information for theInternet community.3221    Huston        Dec 2001        Commentary on Inter-Domain                                        Routing in the InternetThis document examines the various longer term trends visible within thecharacteristics of the Internet's BGP table and identifies a number ofoperational practices and protocol factors that contribute to thesetrends.  The potential impacts of these practices and protocolproperties on the scaling properties of the inter-domain routing spaceare examined.  This memo provides information for the Internetcommunity.Ginoza                       Informational                     [Page 23]

RFC 3299                  Summary of 3200-3299             December 20033220    Perkins       Jan 2002        IP Mobility Support for IPv4This document specifies protocol enhancements that allow transparentrouting of IP datagrams to mobile nodes in the Internet.  Each mobilenode is always identified by its home address, regardless of its currentpoint of attachment to the Internet.  While situated away from its home,a mobile node is also associated with a care-of address, which providesinformation about its current point of attachment to the Internet.  Theprotocol provides for registering the care-of address with a home agent.The home agent sends datagrams destined for the mobile node through atunnel to the care-of address.  After arriving at the end of the tunnel,each datagram is then delivered to the mobile node.  [STANDARDS TRACK]3219    Rosenberg     Jan 2002        Telephony Routing over IP                                        (TRIP)This document presents the Telephony Routing over IP (TRIP).  TRIP is apolicy driven inter-administrative domain protocol for advertising thereachability of telephony destinations between location servers, and foradvertising attributes of the routes to those destinations.  TRIP'soperation is independent of any signaling protocol, hence TRIP can serveas the telephony routing protocol for any signaling protocol.[STANDARDS TRACK]3218    Rescorla      Jan 2002        Preventing the Million Message                                        Attack on Cryptographic                                        Message SyntaxThis memo describes a strategy for resisting the Million Message Attack.This memo provides information for the Internet community.3217    Housley       Dec 2001        Triple-DES and RC2 Key                                        WrappingThis document specifies the algorithm for wrapping one Triple-DES keywith another Triple-DES key and the algorithm for wrapping one RC2 keywith another RC2 key.  This memo provides information for the Internetcommunity.Ginoza                       Informational                     [Page 24]

RFC 3299                  Summary of 3200-3299             December 20033216    Elliott       Dec 2001        SMIng ObjectivesThis document describes the objectives for a new data definitionlanguage, suitable for the modeling of network management constructs,that can be directly mapped into SNMP and COPS-PR protocol operations.This memo provides information for the Internet community.3215    Boscher       Jan 2002        LDP State MachineThis document provides state machine tables for ATM (AsynchronousTransfer Mode) switch LSRs.  In the current LDP specification, there isno state machine specified for processing LDP messages. We think thatdefining a common state machine is very important for interoperabilitybetween different LDP and CR-LDP implementations.  This memo providesinformation for the Internet community.3214    Ash           Jan 2002        LSP Modification Using CR-LDPThis document presents an approach to modify the bandwidth and possiblyother parameters of an established CR-LSP (Constraint-based Routed LabelSwitched Paths) using CR-LDP (Constraint-based Routed Label DistributionProtocol) without service interruption.  [STANDARDS TRACK]3213    Ash           Jan 2002        Applicability Statement for                                        CR-LDPThis document discusses the applicability of Constraint-Based LSP Setupusing LDP.  It discusses possible network applications, extensions toLabel Distribution Protocol (LDP) required to implement constraint-basedrouting, guidelines for deployment and known limitations of theprotocol.  This document is a prerequisite to advancing CR-LDP on thestandards track.  This memo provides information for the Internetcommunity.3212    Jamoussi      Jan 2002        Constraint-Based LSP Setup                                        using LDPThis document specifies mechanisms and TLVs (Type/Length/Value) forsupport of CR-LSPs (constraint-based routed Label Switched Path) usingLDP (Label Distribution Protocol).  [STANDARDS TRACK]Ginoza                       Informational                     [Page 25]

RFC 3299                  Summary of 3200-3299             December 20033211    Gutmann       Dec 2001        Password-based Encryption for                                        CMSThis document provides a method of encrypting data using user-suppliedpasswords and, by extension, any form of variable-length keying materialwhich is not necessarily an algorithm-specific fixed-format key.  TheCryptographic Message Syntax data format does not currently contain anyprovisions for password-based data encryption.  [STANDARDS TRACK]3210    Awduche       Dec 2001        Applicability Statement for                                        Extensions to RSVP for                                        LSP-TunnelsThis memo discusses the applicability of "Extensions to RSVP (ResourceReSerVation Protocol) for LSP Tunnels".  It highlights the protocol'sprinciples of operation and describes the network context for which itwas designed.  Guidelines for deployment are offered and known protocollimitations are indicated.  This document is intended to accompany thesubmission of "Extensions to RSVP for LSP Tunnels" onto the Internetstandards track.  This memo provides information for the Internetcommunity.3209    Awduche       Dec 2001        RSVP-TE: Extensions to RSVP                                        for LSP TunnelsThis document describes the use of RSVP (Resource Reservation Protocol),including all the necessary extensions, to establish label-switchedpaths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flowalong an LSP is completely identified by the label applied at theingress node of the path, these paths may be treated as tunnels.  A keyapplication of LSP tunnels is traffic engineering with MPLS as specifiedinRFC 2702.  [STANDARDS TRACK]Ginoza                       Informational                     [Page 26]

RFC 3299                  Summary of 3200-3299             December 20033208    Speakman      Dec 2001        PGM Reliable Transport                                        Protocol SpecificationPragmatic General Multicast (PGM) is a reliable multicast transportprotocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiplereceivers.  PGM guarantees that a receiver in the group either receivesall data packets from transmissions and repairs, or is able to detectunrecoverable data packet loss.  PGM is specifically intended as aworkable solution for multicast applications with basic reliabilityrequirements.  Its central design goal is simplicity of operation withdue regard for scalability and network efficiency.  This memo defines anExperimental Protocol for the Internet community.3207    Hoffman       Feb 2002        SMTP Service Extension for                                        Secure SMTP over Transport                                        Layer SecurityThis document describes an extension to the SMTP (Simple Mail TransferProtocol) service that allows an SMTP server and client to use TLS(Transport Layer Security) to provide private, authenticatedcommunication over the Internet.  This gives SMTP agents the ability toprotect some or all of their communications from eavesdroppers andattackers.  [STANDARDS TRACK]3206    Gellens       Feb 2002        The SYS and AUTH POP Response                                        CodesThis memo proposes two response codes: SYS and AUTH, which enableclients to unambiguously determine an optimal response to anauthentication failure.  In addition, a new capability (AUTH-RESP-CODE)is defined.  [STANDARDS TRACK]3205    Moore         Feb 2002        On the use of HTTP as a                                        SubstrateRecently there has been widespread interest in using Hypertext TransferProtocol (HTTP) as a substrate for other applications-level protocols.This document recommends technical particulars of such use, includinguse of default ports, URL schemes, and HTTP security mechanisms.  Thisdocument specifies an Internet Best Current Practices for the InternetCommunity, and requests discussion and suggestions for improvements.Ginoza                       Informational                     [Page 27]

RFC 3299                  Summary of 3200-3299             December 20033204    Zimmerer      Dec 2001        MIME media types for ISUP and                                        QSIG ObjectsThis document describes MIME types for application/ISUP andapplication/QSIG objects for use in SIP applications, according to therules defined inRFC 2048.  These types can be used to identify ISUP andQSIG objects within a SIP message such as INVITE or INFO, as might beimplemented when using SIP in an environment where part of the callinvolves interworking to the PSTN.  [STANDARDS TRACK]3203    T'Joens       Dec 2001        DHCP reconfigure extensionThis document defines extensions to DHCP (Dynamic Host ConfigurationProtocol) to allow dynamic reconfiguration of a single host triggered bythe DHCP server (e.g., a new IP address and/or local configurationparameters).  [STANDARDS TRACK]3202    Steinberger   Jan 2002        Definitions of Managed Objects                                        for Frame Relay Service Level                                        DefinitionsThis memo defines an extension of the Management Information Base (MIB)for use with network management protocols in TCP/IP-based internets.  Inparticular, it defines objects for managing the Frame Relay ServiceLevel Definitions.  [STANDARDS TRACK]3201    Steinberger   Jan 2002        Definitions of Managed Objects                                        for Circuit to Interface                                        TranslationThis memo defines an extension of the Management Information Base (MIB)for use with network management protocols in TCP/IP-based internets.  Inparticular, it defines objects for managing the insertion of interestingCircuit Interfaces into the ifTable.  This is important for circuitsthat must be used within other MIB modules which require an ifEntry.  Itallows for integrated monitoring of circuits as well as routing tocircuits using unaltered, pre-existing MIB modules.  [STANDARDS TRACK]3200                                    Never IssuedRFC 3200 was never issued.Ginoza                       Informational                     [Page 28]

RFC 3299                  Summary of 3200-3299             December 2003Security 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.eduGinoza                       Informational                     [Page 29]

RFC 3299                  Summary of 3200-3299             December 2003Full 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 30]