Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
INFORMATIONAL
Network Working Group S. GinozaRequest for Comments: 3499 ISICategory: Informational December 2003Request for Comments Summary RFC Numbers 3400-3499Status of This Memo This RFC is a slightly annotated list of the 100 RFCs fromRFC 3400 throughRFC 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 SummaryThis memo.Ginoza Informational [Page 1]
RFC 3499 Summary of 3400-3499 December 20033498 Kuhfeld Mar 2003 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) ArchitecturesThis 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 networks using SynchronousOptical 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 VideoThis memo specifies an RTP payload format for encapsulating uncompressedHigh Definition Television (HDTV) as defined by the Society of MotionPicture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE isthe main standardizing body in the motion imaging industry and the SMPTE292M standard defines a bit-serial digital interface for local area HDTVtransport. [STANDARDS TRACK]3496 Malis Mar 2003 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic EngineeringThis document specifies a Resource ReSerVation Protocol-TrafficEngineering (RSVP-TE) signaling extension for support of AsynchronousTransfer Mode (ATM) Service Class-aware Multiprotocol Label Switching(MPLS) Traffic Engineering. This memo provides information for theInternet community.Ginoza Informational [Page 2]
RFC 3499 Summary of 3400-3499 December 20033495 Beser Mar 2003 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client ConfigurationThis document defines a Dynamic Host Configuration Protocol (DHCP)option that will be used to configure various devices deployed withinCableLabs architectures. Specifically, the document describes DHCPoption content that will be used to configure one class of CableLabsclient device: a PacketCable Media Terminal Adapter (MTA). The optioncontent defined within this document will be extended as futureCableLabs client devices are developed. [STANDARDS TRACK]3494 Zeilenga Mar 2003 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic StatusThis document recommends the retirement of version 2 of the LightweightDirectory Access Protocol (LDAPv2) and other dependent specifications,and discusses the reasons for doing so. This document recommends RFC1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded)be moved to Historic status. This memo provides information for theInternet community.3493 Gilligan Mar 2003 Basic Socket Interface Extensions for IPv6The de facto standard Application Program Interface (API) for TCP/IPapplications is the "sockets" interface. Although this API wasdeveloped for Unix in the early 1980s it has also been implemented on awide variety of non-Unix systems. TCP/IP applications written using thesockets API have in the past enjoyed a high degree of portability and wewould like the same portability with IPv6 applications. But changes arerequired to the sockets API to support IPv6 and this memo describesthese changes. These include a new socket address structure to carryIPv6 addresses, new address conversion functions, and some new socketoptions. These extensions are designed to provide access to the basicIPv6 features required by TCP and UDP applications, includingmulticasting, while introducing a minimum of change into the system andproviding complete compatibility for existing IPv4 applications.Additional extensions for advanced IPv6 features (raw sockets and accessto the IPv6 extension headers) are defined in another document. Thismemo provides information for the Internet community.Ginoza Informational [Page 3]
RFC 3499 Summary of 3400-3499 December 20033492 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 foruse with Internationalized Domain Names in Applications (IDNA). Ituniquely and reversibly transforms a Unicode string into an ASCIIstring. ASCII characters in the Unicode string are representedliterally, and non-ASCII characters are represented by ASCII charactersthat are allowed in host name labels (letters, digits, and hyphens).This document defines a general algorithm called Bootstring that allowsa string of basic code points to uniquely represent any string of codepoints drawn from a larger set. Punycode is an instance of Bootstringthat 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 andname comparison work in ways that make sense for typical usersthroughout the world. This profile of the stringprep protocol is usedas part of a suite of on-the-wire protocols for internationalizing theDomain 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 usecharacters outside the ASCII repertoire. This document definesinternationalized domain names (IDNs) and a mechanism calledInternationalizing Domain Names in Applications (IDNA) for handling themin a standard fashion. IDNs use characters drawn from a largerepertoire (Unicode), but IDNA allows the non-ASCII characters to berepresented using only the ASCII characters already allowed in so-calledhost names today. This backward-compatible representation is requiredin existing protocols like DNS, so that IDNs can be introduced with nochanges to the existing infrastructure. IDNA is only meant forprocessing domain names, not free text. [STANDARDS TRACK]Ginoza Informational [Page 4]
RFC 3499 Summary of 3400-3499 December 20033489 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 AddressTranslators (NATs) (STUN) is a lightweight protocol that allowsapplications to discover the presence and types of NATs and firewallsbetween them and the public Internet. It also provides the ability forapplications to determine the public Internet Protocol (IP) addressesallocated to them by the NAT. STUN works with many existing NATs, anddoes not require any special behavior from them. As a result, it allowsa wide variety of applications to work through existing NATinfrastructure. [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 usedbetween multicast routers and switches to restrict multicast packetforwarding in switches to those routers where the packets may be needed.RGMP is designed for backbone switched networks where multiple, highspeed routers are interconnected. This memo provides information forthe Internet community.3487 Schulzrinne Feb 2003 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)This document summarizes requirements for prioritizing access tocircuit-switched network, end system and proxy resources for emergencypreparedness 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 isdesired for one or more Session Initiation Protocol (SIP) messages. Italso states when it is appropriate to send compressed SIP messages to aSIP entity. [STANDARDS TRACK]Ginoza Informational [Page 5]
RFC 3499 Summary of 3400-3499 December 20033485 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 forinitiating and managing communication sessions. The protocol can becompressed by using Signaling Compression (SigComp). Similarly, theSession Description Protocol (SDP) is a text-based protocol intended fordescribing 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 SigCompmay use in order to achieve higher efficiency. The dictionary iscompression 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 andfor destination address selection. The algorithms specify defaultbehavior for all Internet Protocol version 6 (IPv6) implementations.They do not override choices made by applications or upper-layerprotocols, nor do they preclude the development of more advancedmechanisms for address selection. The two algorithms share a commoncontext, including an optional mechanism for allowing administrators toprovide policy that can override the default behavior. In dual stackimplementations, the destination address selection algorithm canconsider both IPv4 and IPv6 addresses - depending on the availablesource addresses, the algorithm might prefer IPv6 addresses over IPv4addresses, or vice-versa.All IPv6 nodes, including both hosts and routers, must implement defaultaddress selection as defined in this specification. [STANDARDS TRACK]Ginoza Informational [Page 6]
RFC 3499 Summary of 3400-3499 December 20033483 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 thecapability of reporting information to the Policy Decision Point (PDP).The types of report information are success, failure and accounting ofan installed state. This document focuses on the COPS Report Type ofAccounting and the necessary framework for the monitoring and reportingof usage feedback for an installed state. This memo providesinformation for the Internet community.3482 Foster Feb 2003 Number Portability in the Global Switched Telephone Network (GSTN): An OverviewThis 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 telephonyservice competition, by enabling end-users to retain telephone numberswhile changing service providers. NP changes the fundamental nature ofa dialed E.164 number from a hierarchical physical routing address to avirtual address, thereby requiring the transparent translation of thelater to the former. In addition, there are various regulatoryconstraints that establish relevant parameters for NP implementation,most of which are not network technology specific. Consequently, theimplementation of NP behavior consistent with applicable regulatoryconstraints, as well as the need for interoperation with the existingGSTN NP implementations, are relevant topics for numerous areas of IPtelephony works-in-progress with the IETF. This memo providesinformation for the Internet community.Ginoza Informational [Page 7]
RFC 3499 Summary of 3400-3499 December 20033481 Inamura, Ed. Feb 2003 TCP over Second (2.5G) and Third (3G) Generation Wireless NetworksThis document describes a profile for optimizing TCP to adapt so that ithandles paths including second (2.5G) and third (3G) generation wirelessnetworks. It describes the relevant characteristics of 2.5G and 3Gnetworks, and specific features of example deployments of such networks.It then recommends TCP algorithm choices for nodes known to be startingor ending on such paths, and it also discusses open issues. Theconfiguration options recommended in this document are commonly found inmodern TCP stacks, and are widely available standards-track mechanismsthat the community considers safe for use on the general Internet. Thisdocument specifies an Internet Best Current Practices for the InternetCommunity, 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 TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to Constraint-RoutingLabel Distribution Protocol (CR-LDP), one of the MPLS TE signallingprotocols 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 corenetworks where system downtime must be kept to an absolute minimum.Many MPLS Label Switching Routers (LSRs) may, therefore, exploit FaultTolerant (FT) hardware or software to provide high availability of thecore networks.The details of how FT is achieved for the various components of an FTLSR, including Label Distribution Protocol (LDP), the switching hardwareand TCP, are implementation specific. This document identifies issuesin the LDP specification inRFC 3036, "LDP Specification", that make itdifficult to implement an FT LSR using the current LDP protocols, anddefines enhancements to the LDP specification to ease such FT LSRimplementations.Ginoza Informational [Page 8]
RFC 3499 Summary of 3400-3499 December 2003The issues and extensions described here are equally applicable to RFC3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDSTRACK]3478 Leelanivas Feb 2003 Graceful Restart Mechanism for Label Distribution ProtocolThis document describes a mechanism that helps to minimize the negativeeffects on MPLS traffic caused by Label Switching Router's (LSR's)control plane restart, specifically by the restart of its LabelDistribution Protocol (LDP) component, on LSRs that are capable ofpreserving the MPLS forwarding component across the restart.The mechanism described in this document is applicable to all LSRs, boththose with the ability to preserve forwarding state during LDP restartand those without (although the latter needs to implement only a subsetof the mechanism described in this document). Supporting (a subset of)the mechanism described here by the LSRs that can not preserve theirMPLS forwarding state across the restart would not reduce the negativeimpact on MPLS traffic caused by their control plane restart, but itwould minimize the impact if their neighbor(s) are capable of preservingthe forwarding state across the restart of their control plane andimplement the mechanism described here.The mechanism makes minimalistic assumptions on what has to be preservedacross restart - the mechanism assumes that only the actual MPLSforwarding state has to be preserved; the mechanism does not require anyof the LDP-related states to be preserved across the restart.The procedures described in this document apply to downstreamunsolicited label distribution. Extending these procedures todownstream 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 TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to Resource ReSerVationProtocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one ofthe MPLS TE signalling protocols, that are needed in order to supportunnumbered links. [STANDARDS TRACK]Ginoza Informational [Page 9]
RFC 3499 Summary of 3400-3499 December 20033476 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 SignalingThe Optical Interworking Forum (OIF) has defined extensions to the LabelDistribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP)for optical User Network Interface (UNI) signaling. These extensionsconsist of a set of new data objects and error codes. This documentdescribes these extensions. This memo provides information for theInternet 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, specifiedby ITU-T Study Group 15, for the introduction of a control plane foroptical networks. The ASON architecture specifies a set of referencepoints that defines the relationship between the ASON architecturalentities. Signaling over interfaces defined in those reference pointscan make use of protocols that are defined by the IETF in the context ofGeneralized Multi-Protocol Label Switching (GMPLS) work. This documentdescribes Constraint-Based LSP setup using LDP (CR-LDP) extensions forsignaling over the interfaces defined in the ASON reference points. Thepurpose of the document is to request that the IANA assigns code pointsnecessary for the CR-LDP extensions. The protocol specifications forthe use of the CR-LDP extensions are found in ITU-T documents. Thismemo provides information for the Internet community.Ginoza Informational [Page 10]
RFC 3499 Summary of 3400-3499 December 20033474 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 protocolspecifications has been defined to provide support for differenttechnologies as well as different applications. These include supportfor requesting TDM connections based on Synchronous OpticalNETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as OpticalTransport Networks (OTNs).This document concentrates on the signaling aspects of the GMPLS suiteof protocols, specifically GMPLS signaling using Resource ReservationProtocol - Traffic Engineering (RSVP-TE). It proposes additionalextensions to these signaling protocols to support the capabilities ofan ASON network.This document proposes appropriate extensions towards the resolution ofadditional requirements identified and communicated by the ITU-T StudyGroup 15 in support of ITU's ASON standardization effort. This memoprovides information for the Internet community.3473 Berger Jan 2003 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ExtensionsThis document describes extensions to Multi-Protocol Label Switching(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)signaling required to support Generalized MPLS. Generalized MPLSextends 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 documentpresents a RSVP-TE specific description of the extensions. A genericfunctional description can be found in separate documents. [STANDARDSTRACK]Ginoza Informational [Page 11]
RFC 3499 Summary of 3400-3499 December 20033472 Ashwood-Smith Jan 2003 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) ExtensionsThis document describes extensions to Multi-Protocol Label Switching(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP)signaling required to support Generalized MPLS. Generalized MPLSextends 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 documentpresents a CR-LDP specific description of the extensions. A genericfunctional description can be found in separate documents. [STANDARDSTRACK]3471 Berger Jan 2003 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional DescriptionThis document describes extensions to Multi-Protocol Label Switching(MPLS) signaling required to support Generalized MPLS. Generalized MPLSextends 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 documentpresents a functional description of the extensions. Protocol specificformats and mechanisms, and technology specific details are specified inseparate documents. [STANDARDS TRACK]3470 Hollenbeck Jan 2003 Guidelines for the Use of Extensible Markup Language (XML) within IETF ProtocolsThe Extensible Markup Language (XML) is a framework for structuringdata. While it evolved from Standard Generalized Markup Language (SGML)-- a markup language primarily focused on structuring documents -- XMLhas evolved to be a widely-used mechanism for representing structureddata.Ginoza Informational [Page 12]
RFC 3499 Summary of 3400-3499 December 2003There are a wide variety of Internet protocols being developed; manyhave need for a representation for structured data relevant to theirapplication. There has been much interest in the use of XML as arepresentation method. This document describes basic XML concepts,analyzes various alternatives in the use of XML, and provides guidelinesfor the use of XML within IETF standards-track protocols. This documentspecifies 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 RecoveryMulti-protocol label switching (MPLS) integrates the label swappingforwarding paradigm with network layer routing. To deliver reliableservice, MPLS requires a set of procedures to provide protection of thetraffic carried on different paths. This requires that the labelswitching routers (LSRs) support fault detection, fault notification,and fault recovery mechanisms, and that MPLS signaling support theconfiguration of recovery. With these objectives in mind, this documentspecifies a framework for MPLS based recovery. Restart issues are notincluded in this framework. This memo provides information for theInternet community.3468 Andersson Feb 2003 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocolsThis document documents the consensus reached by the Multiprotocol LabelSwitching (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 protocolfor traffic engineering applications and to undertake no new effortsrelating to "Constraint-Based LSP Setup using Label DistributionProtocol (LDP)" (RFC 3212). The recommendations ofsection 6 have beenaccepted by the IESG. This memo provides information for the Internetcommunity.Ginoza Informational [Page 13]
RFC 3499 Summary of 3400-3499 December 20033467 Klensin Feb 2003 Role of the Domain Name System (DNS)This document reviews the original function and purpose of the domainname system (DNS). It contrasts that history with some of the purposesfor which the DNS has recently been applied and some of the newerdemands being placed upon it or suggested for it. A framework for analternative to placing these additional stresses on the DNS is thenoutlined. This document and that framework are not a proposed solution,only a strong suggestion that the time has come to begin thinking morebroadly about the problems we are encountering and possible approachesto solving them. This memo provides information for the Internetcommunity.3466 Day Feb 2003 A Model for Content Internetworking (CDI)Content (distribution) internetworking (CDI) is the technology forinterconnecting content networks, sometimes previously called "contentpeering" or "CDN peering". A common vocabulary helps the process ofdiscussing such interconnection and interoperation. This documentintroduces content networks and content internetworking, and defineselements for such a common vocabulary. This memo provides informationfor 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 itscongestion window. Rather than the traditional method of increasing thecongestion window by a constant amount for each arriving acknowledgment,the document suggests basing the increase on the number of previouslyunacknowledged bytes each ACK covers. This change improves theperformance of TCP, as well as closes a security hole TCP receivers canuse 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]
RFC 3499 Summary of 3400-3499 December 20033464 Moore Jan 2003 An Extensible Message Format for Delivery Status NotificationsThis memo defines a Multipurpose Internet Mail Extensions (MIME)content-type that may be used by a message transfer agent (MTA) orelectronic mail gateway to report the result of an attempt to deliver amessage to one or more recipients. This content-type is intended as amachine-processable replacement for the various types of delivery statusnotifications currently used in Internet electronic mail.Because many messages are sent between the Internet and other messagingsystems (such as X.400 or the so-called "Local Area Network (LAN)-based"systems), the Delivery Status Notification (DSN) protocol is designed tobe useful in a multi-protocol messaging environment. To this end, theprotocol described in this memo provides for the carriage of "foreign"addresses and error codes, in addition to those normally used inInternet mail. Additional attributes may also be defined to support"tunneling" of foreign notifications through Internet mail. [STANDARDSTRACK]3463 Vaudreuil Jan 2003 Enhanced Mail System Status CodesThis document defines a set of extended status codes for use within themail system for delivery status reports, tracking, and improveddiagnostics. In combination with other information provided in theDelivery Status Notification (DSN) delivery report, these codesfacilitate media and language independent rendering of message deliverystatus. [STANDARDS TRACK]3462 Vaudreuil Jan 2003 The Multipart/Report Content Type for the Reporting of Mail System Administrative MessagesThe Multipart/Report Multipurpose Internet Mail Extensions (MIME)content-type is a general "family" or "container" type for electronicmail reports of any kind. Although this memo defines only the use ofthe Multipart/Report content-type with respect to delivery statusreports, mail processing programs will benefit if a single content-typeis used to for all kinds of reports.Ginoza Informational [Page 15]
RFC 3499 Summary of 3400-3499 December 2003This document is part of a four document set describing the deliverystatus report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports,a MIME content for the reporting of delivery reports, an enumeration ofextended status codes, and a multipart container for the deliveryreport, the original message, and a human-friendly summary of thefailure. [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 DeliveryStatus Notifications (DSNs) should be generated under certainconditions, (b) whether such notifications should return the contents ofthe message, and (c) additional information, to be returned with a DSN,that allows the sender to identify both the recipient(s) for which theDSN was issued, and the transaction in which the original message wassent. [STANDARDS TRACK]3460 Moore Jan 2003 Policy Core Information Model (PCIM) ExtensionsThis document specifies a number of changes to the Policy CoreInformation 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 didnot previously cover. Second, there are cases where elements of PCIM(for example, policy rule priorities) are deprecated, and replacementelements are defined (in this case, priorities tied to associations thatrefer to policy rules). Both types of changes are done in such a waythat, to the extent possible, interoperability with implementations ofthe original PCIM model is preserved. This document updatesRFC 3060.[STANDARDS TRACK]3459 Burger Jan 2003 Critical Content Multi-purpose Internet Mail Extensions (MIME) ParameterThis document describes the use of a mechanism for identifying bodyparts that a sender deems critical in a multi-part Internet mailmessage. The mechanism described is a parameter to Content-Disposition,as described byRFC 3204.Ginoza Informational [Page 16]
RFC 3499 Summary of 3400-3499 December 2003By knowing what parts of a message the sender deems critical, a contentgateway can intelligently handle multi-part messages when providinggateway services to systems of lesser capability. Critical content canhelp a content gateway to decide what parts to forward. It can indicatehow hard a gateway should try to deliver a body part. It can help thegateway to pick body parts that are safe to silently delete when asystem of lesser capability receives a message. In addition, criticalcontent can help the gateway chose the notification strategy for thereceiving system. Likewise, if the sender expects the destination to dosome processing on a body part, critical content allows the sender tomark body parts that the receiver must process. [STANDARDS TRACK]3458 Burger Jan 2003 Message Context for Internet MailThis memo describes a newRFC 2822 message header, "Message-Context".This header provides information about the context and presentationcharacteristics of a message.A receiving user agent (UA) may use this information as a hint tooptimally present the message. [STANDARDS TRACK]3457 Kelly Jan 2003 Requirements for IPsec Remote Access ScenariosIPsec offers much promise as a secure remote access mechanism. However,there are a number of differing remote access scenarios, each havingsome shared and some unique requirements. A thorough understanding ofthese requirements is necessary in order to effectively evaluate thesuitability of a specific set of mechanisms for any particular remoteaccess scenario. This document enumerates the requirements for a numberof common remote access scenarios. This memo provides information forthe Internet community.Ginoza Informational [Page 17]
RFC 3499 Summary of 3400-3499 December 20033456 Patel Jan 2003 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel ModeThis memo explores the requirements for host configuration in IPsectunnel mode, and describes how the Dynamic Host Configuration Protocol(DHCPv4) may be leveraged for configuration. In many remote accessscenarios, a mechanism for making the remote host appear to be presenton the local corporate network is quite useful. This may beaccomplished by assigning the host a "virtual" address from thecorporate network, and then tunneling traffic via IPsec from the host'sISP-assigned address to the corporate security gateway. In IPv4, DHCPprovides 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 particularenvironments. The P-headers are for a variety of purposes within thenetworks that the partners use, including charging and information aboutthe networks a call traverses. This memo provides information for theInternet community.3454 Hoffman Dec 2002 Preparation of Internationalized Strings ("stringprep")This document describes a framework for preparing Unicode text stringsin order to increase the likelihood that string input and stringcomparison work in ways that make sense for typical users throughout theworld. The stringprep protocol is useful for protocol identifiervalues, company and personal names, internationalized domain names, andother text strings.This document does not specify how protocols should prepare textstrings. Protocols must create profiles of stringprep in order to fullyspecify the processing options. [STANDARDS TRACK]Ginoza Informational [Page 18]
RFC 3499 Summary of 3400-3499 December 20033453 Luby Dec 2002 The Use of Forward Error Correction (FEC) in Reliable MulticastThis memo describes the use of Forward Error Correction (FEC) codes toefficiently provide and/or augment reliability for one-to-many reliabledata transport using IP multicast. One of the key properties of FECcodes in this context is the ability to use the same packets containingFEC data to simultaneously repair different packet loss patterns atmultiple receivers. Different classes of FEC codes and some of theirbasic properties are described and terminology relevant to implementingFEC in a reliable multicast protocol is introduced. Examples areprovided of possible abstract formats for packets carrying FEC. Thismemo provides information for the Internet community.3452 Luby Dec 2002 Forward Error Correction (FEC) Building BlockThis document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for datatransport. The primary focus of this document is the application of FECcodes to one-to-many reliable data transport using IP multicast. Thisdocument describes what information is needed to identify a specific FECcode, what information needs to be communicated out-of-band to use theFEC code, and what information is needed in data packets to identify theencoding symbols they carry. The procedures for specifying FEC codesand registering them with the Internet Assigned Numbers Authority (IANA)are also described. This document should be read in conjunction withand uses the terminology of the companion document titled, "The Use ofForward Error Correction (FEC) in Reliable Multicast". This memodefines an Experimental Protocol for the Internet community.3451 Luby Dec 2002 Layered Coding Transport (LCT) Building BlockLayered Coding Transport (LCT) provides transport level support forreliable content delivery and stream delivery protocols. LCT isspecifically designed to support protocols using IP multicast, but alsoprovides support to protocols that use unicast. LCT is compatible withcongestion control that provides multiple rate delivery to receivers andis also compatible with coding techniques that provide reliable deliveryof content. This memo defines an Experimental Protocol for the Internetcommunity.Ginoza Informational [Page 19]
RFC 3499 Summary of 3400-3499 December 20033450 Luby Dec 2002 Asynchronous Layered Coding (ALC) Protocol InstantiationThis document describes the Asynchronous Layered Coding (ALC) protocol,a massively scalable reliable content delivery protocol. AsynchronousLayered Coding combines the Layered Coding Transport (LCT) buildingblock, a multiple rate congestion control building block and the ForwardError Correction (FEC) building block to provide congestion controlledreliable asynchronous delivery of content to an unlimited number ofconcurrent receivers from a single sender. This memo defines anExperimental Protocol for the Internet community.3449 Balakrishnan Dec 2002 TCP Performance Implications of Network Path AsymmetryThis document describes TCP performance problems that arise because ofasymmetric 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 TCPperformance is the same in both cases: performance often degradessignificantly because of imperfection and variability in the ACKfeedback from the receiver to the sender.The document details several mitigations to these effects, which haveeither been proposed or evaluated in the literature, or are currentlydeployed 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 bottlenecklink carrying the ACKs, typically using header compression or reducingthe frequency of TCP ACKs, (ii) techniques to handle this reduced ACKfrequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets inthe reverse direction to improve performance in the presence of two-waytraffic. Each technique is described, together with known issues, andrecommendations for use. A summary of the recommendations is providedat the end of the document. This document specifies an Internet BestCurrent Practices for the Internet Community, and requests discussionand suggestions for improvements.Ginoza Informational [Page 20]
RFC 3499 Summary of 3400-3499 December 20033448 Handley Jan 2003 TCP Friendly Rate Control (TFRC): Protocol SpecificationThis document specifies TCP-Friendly Rate Control (TFRC). TFRC is acongestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing forbandwidth with TCP flows, but has a much lower variation of throughputover time compared with TCP, making it more suitable for applicationssuch as telephony or streaming media where a relatively smooth sendingrate is of importance. [STANDARDS TRACK]3447 Jonsson Feb 2003 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, andchange control is retained within the PKCS process. The body of thisdocument is taken directly from the PKCS #1 v2.1 document, with certaincorrections made during the publication process. This memo providesinformation 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 ofRendevous Points (RPs) per group in a single shared-tree ProtocolIndependent Multicast-Sparse Mode (PIM-SM) domain. This memo providesinformation for the Internet community.Ginoza Informational [Page 21]
RFC 3499 Summary of 3400-3499 December 20033445 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 keysand arbitrary application keys. Storing both DNSSEC and applicationkeys with the same record type is a mistake. This document removesapplication keys from the KEY record by redefining the Protocol Octetfield in the KEY RR Data. As a result of removing application keys, allbut one of the flags in the KEY record become unnecessary and areredefined. Three existing application key sub-types are changed toreserved, but the format of the KEY record is not changed. Thisdocument updatesRFC 2535. [STANDARDS TRACK]3444 Pras Jan 2003 On the Difference between Information Models and Data ModelsThere has been ongoing confusion about the differences betweenInformation Models and Data Models for defining managed objects innetwork management. This document explains the differences betweenthese terms by analyzing how existing network management modelspecifications (from the IETF and other bodies such as the InternationalTelecommunication 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 NetworkManagement Research Group (NMRG) of the Internet Research Task Force(IRTF) hosted by the University of Texas at Austin. This memo providesinformation for the Internet community.3443 Agarwal Jan 2003 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) NetworksThis document describes Time To Live (TTL) processing in hierarchicalMulti-Protocol Label Switching (MPLS) networks and is motivated by theneed to formalize a TTL-transparent mode of operation for an MPLSlabel-switched path. It updatesRFC 3032, "MPLS Label Stack Encoding".TTL processing in both Pipe and Uniform Model hierarchical tunnels arespecified with examples for both "push" and "pop" cases. The documentalso complementsRFC 3270, "MPLS Support of Differentiated Services" andties together the terminology introduced in that document with TTLprocessing in hierarchical MPLS networks. [STANDARDS TRACK]Ginoza Informational [Page 22]
RFC 3499 Summary of 3400-3499 December 20033442 Lemon Dec 2002 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4This document defines a new Dynamic Host Configuration Protocol (DHCP)option which is passed from the DHCP Server to the DHCP Client toconfigure a list of static routes in the client. The networkdestinations in these routes are classless - each routing table entryincludes 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 forthe Media Gateway Control Protocol (MGCP). This package includes newLocal Connection Options, ATM-specific events and signals, and ATMconnection parameters. Also included is a description of codec andprofile negotiation. It extends the MGCP that is currently beingdeployed in a number of products. Implementers should be aware ofdevelopments in the IETF Megaco Working Group and ITU SG16, which arecurrently working on a potential successor to this protocol. This memoprovides information for the Internet community.3440 Ly Dec 2002 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber LinesThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes additional managed objects used for managingAsymmetric Digital Subscriber Line (ADSL) interfaces not covered by theADSL Line MIB (RFC 2662). [STANDARDS TRACK]Ginoza Informational [Page 23]
RFC 3499 Summary of 3400-3499 December 20033439 Bush Dec 2002 Some Internet Architectural Guidelines and PhilosophyThis document extendsRFC 1958 by outlining some of the philosophicalguidelines to which architects and designers of Internet backbonenetworks should adhere. We describe the Simplicity Principle, whichstates that complexity is the primary mechanism that impedes efficientscaling, and discuss its implications on the architecture, design andengineering issues found in large scale Internet backbones. This memoprovides information for the Internet community.3438 Townsley Dec 2002 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations UpdateThis document describes updates to the Internet Assigned NumbersAuthority (IANA) considerations for the Layer Two Tunneling Protocol(L2TP). This document specifies an Internet Best Current Practices forthe Internet Community, and requests discussion and suggestions forimprovements.3437 Palter Dec 2002 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol NegotiationThis 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 commonphysical media connecting them and thus have detailed knowledge aboutthe media that is in use. When the L2TP is used, the two PPP peers areno longer directly connected over the same physical media. Instead,L2TP inserts a virtual connection over some or all of the PPP connectionby tunneling PPP frames over a packet switched network such as IP.Under some conditions, an L2TP endpoint may need to negotiate PPP LinkControl Protocol (LCP) options at a location which may not have accessto all of the media information necessary for proper participation inthe LCP negotiation. This document provides a mechanism forcommunicating desired LCP options between L2TP endpoints in advance ofPPP LCP negotiation at the far end of an L2TP tunnel, as well as amechanism for communicating the negotiated LCP options back to where thenative PPP link resides. [STANDARDS TRACK]Ginoza Informational [Page 24]
RFC 3499 Summary of 3400-3499 December 20033436 Jungmaier Dec 2002 Transport Layer Security over Stream Control Transmission ProtocolThis document describes the usage of the Transport Layer Security (TLS)protocol, as defined inRFC 2246, over the Stream Control TransmissionProtocol (SCTP), as defined inRFC 2960 andRFC 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 blockingand the support of multi-homing to provide network level faulttolerance.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.0This document describes an application programming interface and acorresponding protocol (MGCP) which is used between elements of adecomposed multimedia gateway. The decomposed multimedia gatewayconsists 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 mediasessions with other multimedia endpoints. Also, the Call Agent caninstruct the endpoints to detect certain events and generate signals.The endpoints automatically communicate changes in service state to theCall Agent. Furthermore, the Call Agent can audit endpoints as well asthe connections on endpoints.The basic and general MGCP protocol is defined in this document, howevermost media gateways will need to implement one or more MGCP packages,which define extensions to the protocol suitable for use with specifictypes of media gateways. Such packages are defined in separatedocuments. This memo provides information for the Internet community.Ginoza Informational [Page 25]
RFC 3499 Summary of 3400-3499 December 20033434 Bierman Dec 2002 Remote Monitoring MIB Extensions for High Capacity AlarmsThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for extending the alarmthresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC2819), to provide similar threshold monitoring of objects based on theCounter64 data type. [STANDARDS TRACK]3433 Bierman Dec 2002 Entity Sensor Management Information BaseThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for extending the Entity MIB(RFC 2737) to provide generalized access to information related tophysical sensors, which are often found in networking equipment (such aschassis temperature, fan RPM, power supply voltage). [STANDARDS TRACK]3432 Raisanen Nov 2002 Network performance measurement with periodic streamsThis memo describes a periodic sampling method and relevant metrics forassessing the performance of IP networks. First, the memo motivatesperiodic sampling and addresses the question of its value as analternative to the Poisson sampling described inRFC 2330. The benefitsinclude applicability to active and passive measurements, simulation ofconstant bit rate (CBR) traffic (typical of multimedia communication, ornearly CBR, as found with voice activity detection), and severalinstances in which analysis can be simplified. The sampling methodavoids predictability by mandating random start times and finite lengthtests. Following descriptions of the sampling method and sample metricparameters, measurement methods and errors are discussed. Finally, wegive additional information on periodic measurements, including securityconsiderations. [STANDARDS TRACK]Ginoza Informational [Page 26]
RFC 3499 Summary of 3400-3499 December 20033431 Segmuller Dec 2002 Sieve Extension: Relational TestsThis document describes the RELATIONAL extension to the Sieve mailfiltering language defined inRFC 3028. This extension extends existingconditional tests in Sieve to allow relational operators. In additionto testing their content, it also allows for testing of the number ofentities in header and envelope fields. [STANDARDS TRACK]3430 Schoenwaelder Dec 2002 Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport MappingThis memo defines a transport mapping for using the Simple NetworkManagement Protocol (SNMP) over TCP. The transport mapping can be usedwith any version of SNMP. This document extends the transport mappingsdefined in STD 62,RFC 3417. This memo defines an Experimental Protocolfor the Internet community.3429 Ohta Nov 2002 Assignment of the 'OAM Alert Label' forMultiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) FunctionsThis document describes the assignment of one of the reserved labelvalues defined inRFC 3032 (MPLS label stack encoding) to the 'Operationand Maintenance (OAM) Alert Label' that is used by user-planeMultiprotocol Label Switching Architecture (MPLS) OAM functions foridentification of MPLS OAM packets. This memo provides information forthe Internet community.3428 Campbell Dec 2002 Session Initiation Protocol (SIP) Extension for Instant MessagingInstant Messaging (IM) refers to the transfer of messages between usersin near real-time. These messages are usually, but not required to be,short. IMs are often used in a conversational mode, that is, thetransfer of messages back and forth is fast enough for participants tomaintain an interactive conversation.Ginoza Informational [Page 27]
RFC 3499 Summary of 3400-3499 December 2003This document proposes the MESSAGE method, an extension to the SessionInitiation Protocol (SIP) that allows the transfer of Instant Messages.Since the MESSAGE request is an extension to SIP, it inherits all therequest routing and security features of that protocol. MESSAGErequests carry the content in the form of MIME body parts. MESSAGErequests do not themselves initiate a SIP dialog; under normal usageeach Instant Message stands alone, much like pager messages. MESSAGErequests may be sent in the context of a dialog initiated by some otherSIP request. [STANDARDS TRACK]3427 Mankin Dec 2002 Change Process for the Session Initiation Protocol (SIP)This memo documents a process intended to apply architectural disciplineto 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 damagingtowards security and/or greatly increase the complexity of the protocol.The Transport Area directors, along with the SIP and Session InitiationProposal Investigation (SIPPING) working group chairs, have providedsuggestions for SIP modifications and extensions. This documentspecifies an Internet Best Current Practices for the Internet Community,and requests discussion and suggestions for improvements.3426 Floyd Nov 2002 General Architectural and Policy ConsiderationsThis document suggests general architectural and policy questions thatthe IETF community has to address when working on new standards andprotocols. We note that this document contains questions to beaddressed, as opposed to guidelines or architectural principles to befollowed. This memo provides information for the Internet community.3425 Lawrence Nov 2002 Obsoleting IQUERYThe IQUERY method of performing inverse DNS lookups, specified in RFC1035, has not been generally implemented and has usually beenoperationally disabled where it has been implemented. Both reflect ageneral view in the community that the concept was unwise and that thewidely-used alternate approach of using pointer (PTR) queries andreverse-mapping records is preferable. Consequently, this documentdeprecates the IQUERY operation, declaring it entirely obsolete. Thisdocument updatesRFC 1035. [STANDARDS TRACK]Ginoza Informational [Page 28]
RFC 3499 Summary of 3400-3499 December 20033424 Daigle Nov 2002 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address TranslationAs a result of the nature of Network Address Translation (NAT)Middleboxes, communicating endpoints that are separated by one or moreNATs do not know how to refer to themselves using addresses that arevalid 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 originatingendpoint attempts to determine or fix the address (and port) by which itis known to another endpoint - e.g., to be able to use address data inthe protocol exchange, or to advertise a public address from which itwill receive connections.This document outlines the reasons for which these proposals can beconsidered at best as short term fixes to specific problems and thespecific issues to be carefully evaluated before creating an UNSAFproposal. 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.0This document defines the Common Reliable Accounting for Network Element(CRANE) protocol that enables efficient and reliable delivery of anydata, mainly accounting data from Network Elements to any systems, suchas mediation systems and Business Support Systems (BSS)/ OperationsSupport Systems (OSS). The protocol is developed to address thecritical needs for exporting high volume of accounting data from NE'swith efficient use of network, storage, and processing resources.This document specifies the architecture of the protocol and the messageformat, which MUST be supported by all CRANE protocol implementations.This memo provides information for the Internet community.Ginoza Informational [Page 29]
RFC 3499 Summary of 3400-3499 December 20033422 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 OpticalNetwork/Synchronous Digital Hierarchy (MAPOS), thus providing a way tounify 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 ServiceLocation Protocol (SLP). These extensions allow a User Agent (UA) torequest that the Uniform Resource Locator (URL) entries in a ServiceReply (SrvRply) be limited to the specified number, or be sortedaccording to the specified sort key list. Using these two extensionstogether can facilitate discovering the best match, such as finding aservice that has the maximum speed or the minimum load. This memodefines an Experimental Protocol for the Internet community.3420 Sparks Nov 2002 Internet Media Type message/sipfragThis document registers the message/sipfrag Multipurpose Internet MailExtensions (MIME) media type. This type is similar to message/sip, butallows 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 withthe REFER method to convey information about the status of a referencedrequest. [STANDARDS TRACK]Ginoza Informational [Page 30]
RFC 3499 Summary of 3400-3499 December 20033419 Daniele Dec 2002 Textual Conventions for Transport AddressesThis document introduces a Management Information Base (MIB) module thatdefines textual conventions to represent commonly used transport-layeraddressing information. The definitions are compatible with the conceptof TAddress/TDomain pairs introduced by the Structure of ManagementInformation version 2 (SMIv2) and support the Internet transportprotocols 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 aSimple Network Management Protocol (SNMP) entity. This documentobsoletesRFC 1907, Management Information Base for Version 2 of theSimple 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 ManagementProtocol (SNMP) messages over various protocols. This documentobsoletesRFC 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 theSimple Network Management Protocol (SNMP). It defines the syntax andelements of procedure for sending, receiving, and processing SNMP PDUs.This document obsoletesRFC 1905. [STANDARDS TRACK]Ginoza Informational [Page 31]
RFC 3499 Summary of 3400-3499 December 20033415 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) foruse in the Simple Network Management Protocol (SNMP) architecture. Itdefines the Elements of Procedure for controlling access to managementinformation. This document also includes a Management Information Base(MIB) for remotely managing the configuration parameters for the View-based Access Control Model. This document obsoletesRFC 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 SimpleNetwork Management Protocol (SNMP) version 3 for use in the SNMParchitecture. It defines the Elements of Procedure for providing SNMPmessage level security. This document also includes a ManagementInformation Base (MIB) for remotely monitoring/managing theconfiguration parameters for this Security Model. This documentobsoletesRFC 2574. [STANDARDS TRACK]3413 Levi Dec 2002 Simple Network Management Protocol (SNMP) ApplicationsThis document describes five types of Simple Network Management Protocol(SNMP) applications which make use of an SNMP engine as described in STD62,RFC 3411. The types of application described are CommandGenerators, Command Responders, Notification Originators, NotificationReceivers, and Proxy Forwarders.This document also defines Management Information Base (MIB) modules forspecifying targets of management operations, for notification filtering,and for proxy forwarding. This document obsoletesRFC 2573. [STANDARDSTRACK]Ginoza Informational [Page 32]
RFC 3499 Summary of 3400-3499 December 20033412 Case Dec 2002 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)This document describes the Message Processing and Dispatching forSimple Network Management Protocol (SNMP) messages within the SNMParchitecture. It defines the procedures for dispatching potentiallymultiple versions of SNMP messages to the proper SNMP Message ProcessingModels, and for dispatching PDUs to SNMP applications. This documentalso describes one Message Processing Model - the SNMPv3 MessageProcessing Model. This document obsoletesRFC 2572. [STANDARDS TRACK]3411 Harrington Dec 2002 An Architecture for Describing Simple Network Management Protocol (SNMP) Management FrameworksThis document describes an architecture for describing Simple NetworkManagement Protocol (SNMP) Management Frameworks. The architecture isdesigned to be modular to allow the evolution of the SNMP protocolstandards over time. The major portions of the architecture are an SNMPengine containing a Message Processing Subsystem, a Security Subsystemand an Access Control Subsystem, and possibly multiple SNMP applicationswhich provide specific functional processing of management data. Thisdocument obsoletesRFC 2571. [STANDARDS TRACK]3410 Case Dec 2002 Introduction and Applicability Statements for Internet Standard Management FrameworkThe purpose of this document is to provide an overview of the thirdversion of the Internet-Standard Management Framework, termed the SNMPversion 3 Framework (SNMPv3). This Framework is derived from and buildsupon 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 theFramework over time.The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 isstrongly recommended. The document also recommends that RFCs 1157,1441, 1901, 1909 and 1910 be retired by moving them to Historic status.This document obsoletesRFC 2570. This memo provides information forthe Internet community.Ginoza Informational [Page 33]
RFC 3499 Summary of 3400-3499 December 20033409 Svanbro Dec 2002 Lower Layer Guidelines for Robust RTP/UDP/IP Header CompressionThis document describes lower layer guidelines for robust headercompression (ROHC) and the requirements ROHC puts on lower layers. Thepurpose of this document is to support the incorporation of robustheader compression algorithms, as specified in the ROHC working group,into different systems such as those specified by Third GenerationPartnership Project (3GPP), 3GPP Project 2 (3GPP2), European TechnicalStandards Institute (ETSI), etc. This document covers only lower layerguidelines for compression of RTP/UDP/IP and UDP/IP headers as specifiedin [RFC3095]. Both general guidelines and guidelines specific forcellular systems are discussed in this document. This memo providesinformation 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) ProfileThis document defines an additional mode of the link-layer assistedRObust Header Compression (ROHC) profile, also known as the zero-byteprofile, beyond the two defined inRFC 3242. Zero-byte headercompression exists in order to prevent the single-octet ROHC header frompushing a packet voice stream into the next higher fixed packet size forthe radio. It is usable in certain widely deployed older airinterfaces. This document adds the zero-byte operation for ROHCBidirectional Reliable mode (R-mode) to the ones specified forUnidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes ofheader compression inRFC 3242. [STANDARDS TRACK]3407 Andreasen Oct 2002 Session Description Protocol (SDP) Simple Capability DeclarationThis document defines a set of Session Description Protocol (SDP)attributes that enables SDP to provide a minimal and backwardscompatible capability declaration mechanism. Such capabilitydeclarations can be used as input to a subsequent session negotiation,which is done by means outside the scope of this document. Thisprovides a simple and limited solution to the general capabilitynegotiation problem being addressed by the next generation of SDP, alsoknown as SDPng. [STANDARDS TRACK]Ginoza Informational [Page 34]
RFC 3499 Summary of 3400-3499 December 20033406 Daigle Oct 2002 Uniform Resource Names (URN) Namespace Definition MechanismsThis document lays out general definitions of and mechanisms forestablishing Uniform Resource Names (URN) "namespaces". The URN WG hasdefined a syntax for URNs inRFC 2141, as well as some proposedmechanisms for their resolution and use in Internet applications in RFC3401 andRFC 3405.The whole rests on the concept of individual"namespaces" within the URN structure. Apart from proof-of-conceptnamespaces, the use of existing identifiers in URNs has been discussedinRFC 2288. This document specifies an Internet Best Current Practicesfor the Internet Community, and requests discussion and suggestions forimprovements.3405 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment ProceduresThis document is fifth in a series that is completely specified in"Dynamic Delegation Discovery System (DDDS) Part One: The ComprehensiveDDDS" (RFC 3401). It is very important to note that it is impossible toread and understand any document in this series without reading theothers. This document specifies an Internet Best Current Practices forthe Internet Community, and requests discussion and suggestions forimprovements.3404 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution ApplicationThis document describes a specification for taking Uniform ResourceIdentifiers (URI) and locating an authoritative server for informationabout that URI. The method used to locate that authoritative server isthe Dynamic Delegation Discovery System.This document is part of a series that is specified in "DynamicDelegation Discovery System (DDDS) Part One: The Comprehensive DDDS"(RFC 3401). It is very important to note that it is impossible to readand understand any document in this series without reading the others.[STANDARDS TRACK]Ginoza Informational [Page 35]
RFC 3499 Summary of 3400-3499 December 20033403 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) DatabaseThis document describes a Dynamic Delegation Discovery System (DDDS)Database using the Domain Name System (DNS) as a distributed database ofRules. The Keys are domain-names and the Rules are encoded using theNaming Authority Pointer (NAPTR) Resource Record (RR).Since this document obsoletesRFC 2915, it is the official specificationfor the NAPTR DNS Resource Record. It is also part of a series that iscompletely specified in "Dynamic Delegation Discovery System (DDDS) PartOne: The Comprehensive DDDS" (RFC 3401). It is very important to notethat it is impossible to read and understand any document in this serieswithout reading the others. [STANDARDS TRACK]3402 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Two: The AlgorithmThis document describes the Dynamic Delegation Discovery System (DDDS)algorithm for applying dynamically retrieved string transformation rulesto an application-unique string. Well-formed transformation rules willreflect the delegation of management of information associated with thestring. This document is also part of a series that is completelyspecified in "Dynamic Delegation Discovery System (DDDS) Part One: TheComprehensive DDDS" (RFC 3401). It is very important to note that it isimpossible to read and understand any document in this series withoutreading the others. [STANDARDS TRACK]3401 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDSThis document specifies the exact documents that make up the completeDynamic Delegation Discovery System (DDDS). DDDS is an abstractalgorithm for applying dynamically retrieved string transformation rulesto an application-unique string. This document along withRFC 3402, RFC3403 andRFC 3404 obsoleteRFC 2168 andRFC 2915, as well as updates RFC2276. This memo provides information for the Internet community.Ginoza Informational [Page 36]
RFC 3499 Summary of 3400-3499 December 20033400 Never IssuedRFC 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.eduGinoza Informational [Page 37]
RFC 3499 Summary of 3400-3499 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 38]
[8]ページ先頭