|
Internet Drafts - IDs for May/2008
Index - Month Index of IDs
All IDs - sorted by date)
31/05/2008
| |
|
| |
| | User-Defined Errors for RSVP |
| |
|
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP. This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. |
30/05/2008
| |
|
| |
| | Proxy Mobile IPv6 |
| |
| | draft-ietf-netlmm-proxymip6-18.txt |
| | Date: |
30/05/2008 |
| | Authors: |
Sri Gundavelli, Kent Leung, Vijay Devarapalli, Kuntal Chowdhury, Basavaraj Patil |
| | Working Group: |
Network-based Localized Mobility Management (netlmm) |
| | Formats: |
txt |
|
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility related signaling. The Network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. |
| | Sieve Email Filtering: Date and Index Extensions |
| |
|
This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. Change History (to be removed prior to publication as an RFC) Changed usage from Julian Days to Modified Julian Days. This has the advantage that the number are smaller and day numbers change at midnight rather than at noon. Added the ability to return the day of the week. Use the term "argument" instead of "parameter" throughout. Added a "std11" part type as a means to operate on values formatted in the same way as a Date: header field. Changed the terminology from "part" to "date-part". Updated reference to 3028bis, corrected miscellaneous typos. Updated the IANA registration templates. Added "time" and "date" as possible date-part values with appropriate syntax. Restricted allowed ISO 8601 formats so that comparisons will be reliable. Changed the date-part "timezone" to "zone" to make it consistent with the :zone parameter. Removed the reference to structured header fields in the description of the date test. Added a paragraph to make it clear that :index counts header fields, not the contents of header fields. Allow leap seconds. Added :originalzone parameter to date test. Added several examples. Made the specification of :last without :index an error, aligning this specification with editheader. Added some security considerations text about the impact of currentdate on script analysis. Updated references to recently published RFCs. Clarified that date tests must return false for dates that aren't valid according to the calendar system. Correct erroneous reference to Julian calendar dates - should be Gregorian instead. Clarified that "std11" isn't really intended to be used in comparison operations and added an example of using "std11" to insert a date/ time in a header field. Added an appendix giving sample code to convert to and from modified Julian date values. Simplified the requirements for extracting date information from header fields. |
| | HELD Identity Extensions |
| |
|
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is appropriate in many environments. However, when an entity acting on behalf of the Target would like to request location information then the source IP address of the request will lead to wrong results. In other cases the IP address is not the only identifier that serves as an input to the location determination procedure. This document extends the HELD protocol to allow the location request message to carry additional identifiers assisting the location determination process. It defines a set of URNs for Target identifiers and an XML containment schema. As such, this extension is used in conjunction with HELD to provide Target identification. Examples and usage in HELD message syntax are provided. |
| | Quick-Start for Datagram Congestion Control Protocol (DCCP) |
| |
|
This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID-2 and CCID-3. Quick-Start enables a DCCP sender to cooperate with any Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start and, at times, in the middle of a DCCP connection (e.g., after an idle or application-limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. |
| | DHCPv6 Prefix Delegation for NEMO |
| |
| | draft-droms-mext-nemo-pd-00.txt |
| | Date: |
30/05/2008 |
| | Authors: |
Ralph Droms, Pascal Thubert, Francis Dupont, Wassim Haddad |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. |
| | Multicast Negative-Acknowledgment (NACK) Building Blocks |
| |
|
This document discusses the creation of reliable multicast protocols utilizing negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. |
29/05/2008
| |
|
| |
| | Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers |
| |
|
Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. |
| | A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure |
| |
|
The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). |
| | Multiple Care-of Addresses Registration |
| |
|
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. |
| | Simple SIP Usage Scenario for Applications in the Endpoints |
| |
|
For Internet-centric usage, the number of SIP related standards for presence, IM and audio/video communications can be reduced by using only the rendezvous and session initiation capabilities of SIP. Such 'simple SIP' implies (1) using SIP without network based features and (2) without emulating the telephone network. Rich applications, including telephony features can however be implemented in the endpoints. This approach for SIP reduces the number of SIP standards to comply with, currently from roughly 100 to about 9. Additional application examples and references for NAT traversal and for security are also provided. |
| | IANA Considerations for the IPv4 and IPv6 Router Alert Option |
| |
|
This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. |
| | LoWPAN simple fragment Recovery |
| |
|
Considering that 6LoWPAN packets can be as large as 2K bytes and that an 802.15.4 frame with security will carry in the order of 80 bytes of effective payload, a packet might end up fragmented into as many as 25 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to recover individual fragments between 6LoWPAN endpoints. |
| | WebDAV Current Principal Extension |
| |
|
This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. |
| | In-Vehicle Routing Requirements in Low Power and Lossy Networks |
| |
|
This document presents the routing requirements for in-vehicle low power and lossy networks. Automobiles are already equipped with several sensors and devices named Electronic Control Unit (ECU) for controlling, monitoring and entertainment, etc. For the future in- vehicle networks, the shift to wireless is desirable due to heavy weight and volume of cables in vehicles and to be able to efficiently install devices. However, with the limitation of low power, in- vehicle network still requires reliability and scalability in nature of the rolls of ECU. The routing protocol should support the features of low-power, high-reliability, Subnetting, QoS, Mobility, etc. This document briefly explains the in-vehicle networks and ECUs, then discusses the requirements for the future wireless in- vehicle networks. |
| | Aggregate Server Access Protocol (ASAP) |
| |
| | draft-ietf-rserpool-asap-20.txt |
| | Date: |
29/05/2008 |
| | Authors: |
Randall Stewart, Qiaobing Xie, Maureen Stillman, Michael Tuexen |
| | Working Group: |
Reliable Server Pooling (rserpool) |
| | Formats: |
txt |
|
Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) [I-D.ietf-rserpool-enrp] provides a high availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) [RFC4960]. Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between PE's and ENRP servers MUST use the SCTP transport protocol. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for pool handle to address translation, load sharing management, and fault management while ENRP defines the high availability pool handle translation service. |
| | Endpoint Handlespace Redundancy Protocol (ENRP) |
| |
| | draft-ietf-rserpool-enrp-20.txt |
| | Date: |
29/05/2008 |
| | Authors: |
Qiaobing Xie, Randall Stewart, Maureen Stillman, Michael Tuexen, Aron Silverton |
| | Working Group: |
Reliable Server Pooling (rserpool) |
| | Formats: |
txt |
|
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. |
| | Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters |
| |
|
This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) protocols defined within the Reliable Server Pooling (RSerPool) architecture. |
| | Reliable Server Pooling Policies |
| |
|
This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at ENRP servers and pool users. |
| | A Document Format for Requesting Consent |
| |
|
This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. |
| | VoIP SIP Peering Use Cases |
| |
|
This document depicts many common VoIP use case for SIP Peering. These use cases are categorized into static and on-demand, and then further sub-categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. This document captures them to provide a reference. |
| | Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode |
| |
|
RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes a set of cipher suites for TLS/DTLS which uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another which uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). |
28/05/2008
| |
|
| |
| | Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) |
| |
| | draft-ietf-ccamp-gmpls-mln-reqs-11.txt |
| | Date: |
28/05/2008 |
| | Authors: |
Kohei Shiomoto, Dimitri Papadimitriou, Jean-Louis Roux, Martin Vigoureux, Deborah Brungard, Eiji Oki, Ichiro Inoue, Emmanuel Dotaro |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
| | Formats: |
txt |
|
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. Expires November 2008 [page 1] draft-ietf-ccamp-gmpls-mln-reqs-11.txt May 2008 In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. |
| | LoST: A Location-to-Service Translation Protocol |
| |
| | draft-ietf-ecrit-lost-10.txt |
| | Date: |
28/05/2008 |
| | Authors: |
Ted Hardie, Andrew Newton, Henning Schulzrinne, Hannes Tschofenig |
| | Working Group: |
Emergency Context Resolution with Internet Technologies (ecrit) |
| | Formats: |
txt |
|
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. |
| | An updated IDNA criterion for right-to-left scripts |
| |
| | draft-ietf-idnabis-bidi-00.txt |
| | Date: |
28/05/2008 |
| | Authors: |
Harald Alvestrand, Cary Karp |
| | Working Group: |
Internationalized Domain Names in Applications (Revised) (idnabis) |
| | Formats: |
txt xml |
|
The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI criterion for IDNA labels. |
| | Applicability of Loop-free Convergence |
| |
|
This draft describes the applicability of loop free convergence technologies to a number of network applications. |
| | Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator |
| |
|
In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network. |
| | Service Selection for Mobile IPv4 |
| |
|
In some Mobile IPv4 deployments identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection Extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for the mobility service subscription during the registration procedure. |
| | Securing Neighbour Discovery Proxy Problem Statement |
| |
|
Neighbour Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Neighbour Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for neighbour discovery messages. Neighbour Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbour Discovery relates to Secured Neighbour Discovery. |
| | Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary |
| |
|
LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not give information about the geographical region, for which the returned service list is valid. Therefore this document proposes a ServiceListBoundary, in addition to the ServiceBoundary (which indicates the region a specific service URL is valid). |
| | Guidelines to authors and reviewers regarding the IETF review process |
| |
|
This document describes the IETF review process and provides guidelines to draft authors and reviewers on how to effectively participate in it. |
| | Classification of Location-based Services |
| |
|
This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). |
| | Pseudowire Congestion Control Framework |
| |
|
Pseudowires are sometimes used to carry non-TCP data flows. In these circumstances the service payload will not react to network congestion by reducing its offered load. Pseudowires should therefore reduces their network bandwidth demands in the face of significant packet loss, including if necessary completely ceasing transmission. Since it is difficult to determine a priori the number of equivalent TCP flow that a pseudowire represents, a suitably "fair" rate of back-off cannot be pre-determined. This document describes pseudowire congestion problem and provides guidance on the development suitable solutions. |
| | Requesting Answering Modes for the Session Initiation Protocol (SIP) |
| |
|
This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. |
| | vCard Extensions to WebDAV (CardDAV) |
| |
|
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. Discussion of this Internet-Draft is taking place on the mailing list . |
27/05/2008
| |
|
| |
| | Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE |
| |
| | draft-ietf-ccamp-rfc4420bis-03.txt |
| | Date: |
27/05/2008 |
| | Authors: |
Adrian Farrel, Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
| | Formats: |
txt |
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. |
| | Internationalized Domain Names in Applications (IDNA): Protocol |
| |
|
This document supplies the protocol definition for a revised and updated specification for internationalized domain names (IDNs). The rationale for these changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalizing Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. |
| | Layer 1 VPN Basic Mode |
| |
|
This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM). L1VPN Basic mode is a port-based VPN. In L1VPN Basic Mode (BM), the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port-topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. |
| | DNSSEC Validator API |
| |
|
The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not specify how a validating stub resolver should communicate detailed results of DNSSEC processing back to the application. This document describes an API between applications and a validating stub resolver that allows applications to control the DNSSEC validation process and obtain results of DNSSEC processing. |
| | What Makes For a Successful Protocol? |
| |
|
The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. |
| | Atom Link Relation: Discuss |
| |
|
This specification defines a link relation that enables an Atom document to point to a venue for multi-party discussion of the document or its primary topic. |
| | Sieve Email Filtering: Reject and Extended Reject Extensions |
| |
|
This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028. A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible. The "ereject" action is intended to replace the "reject" action wherever possible. |
26/05/2008
| |
|
| |
| | Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction |
| |
| | draft-ietf-dime-mip6-integrated-09.txt |
| | Date: |
26/05/2008 |
| | Authors: |
Jouni Korhonen, Julien Bournelle, Hannes Tschofenig, Charles Perkins, Kuntal Chowdhury |
| | Working Group: |
Diameter Maintenance and Extensions (dime) |
| | Formats: |
txt xml |
|
A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. |
| | Quality of Service Parameters for Usage with the AAA Framework |
| |
|
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. |
| | Specifying Location Quality Constraints in Location Protocols |
| |
|
Parameters that define the expected quality of location information are defined for use in location protocols. These parameter can be used by a requester to indicate to a Location Server the desired constraints on the quality of the location information provided. If applicable, the Location Server is able to use this information to control how location information is determined. An optional indication of whether the quality constraints were met is defined to be provided by the Location Server alongside location information. |
| | Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) |
| |
|
This document introduces a Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP), which is useful for the access control application of SNMP protocol. This document describes the procedure of access control in SVACM with Remote Authentication Dial In User Service (RADIUS) server for authorization. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for SVACM. |
| | Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) |
| |
|
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes an BEEP feature that enables asynchrony for individual channels. |
| | Message Body Handling in the Session Initiation Protocol (SIP) |
| |
|
This document specifies how message bodies are handled in SIP. Additionally, it specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. |
| | The Session Initiation Protocol (SIP) Pending Additions Event Package |
| |
|
This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. |
25/05/2008
| |
|
| |
| | Sieve Email Filtering: Ihave Extension |
| |
|
This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. |
| | Principles of Internet Host Configuration |
| |
| | draft-iab-ip-config-04.txt |
| | Date: |
25/05/2008 |
| | Authors: |
Bernard Aboba, Dave Thaler, Loa Andersson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols. |
| | Post-Repair Loss RLE Report Block Type for RTCP XR |
| |
|
This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all error-repair techniques are applied. By comparing the RTP packet receipts/losses before and after the error repair is completed, one can determine the effectiveness of the error-repair techniques in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP). |
24/05/2008
| |
|
| |
| | An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP) |
| |
|
This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP). This work is being discussed on the bliss@ietf.org mailing list. |
| | DKIM Third-Party Authorization for Author Domain Signing Practices |
| |
|
TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to authorize Third-Party domains. This mechanism allows first-party domains to autonomously authorize a range of third-party domains in a scalable, individual DNS transaction. This authorization extends the scope of DKIM policy assertions to supplant more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate the coordination between two or more domains by setting up selector/key DNS records, DNS zone delegations, or the regular exchange of public/ private keys. Checking DKIM policies may occur when a From header email-address is not within the domain of a valid DKIM signature. When a Third-Party signature is found, TPA-labels offer an efficient means for email address domains to authorize specific third-party signing domains. The scope of the authorization may separately assert identity authentication for From and Sender and Resent-* headers for email- addresses within the authorizing domain. Identity authentication can be asserted by the scope of the authorization, even when signed by a Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize domains for controlling DSNs. |
23/05/2008
| |
|
| |
| | Signaling media decoding dependency in Session Description Protocol (SDP) |
| |
|
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streamsas a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). |
| | RPCSEC_GSS Version 2 |
| |
|
This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as Version 1 but adds support for channel bindings. |
| | DKIM Author Domain Signing Practices (ADSP) |
| |
| | draft-levine-dkim-adsp-00.txt |
| | Date: |
23/05/2008 |
| | Authors: |
agent Local-part, Author Domain, Jon Callas, John Levine, Ellen Siegel |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether they sign their outgoing mail, and how other hosts can access those records. |
| | Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol |
| |
| | draft-ietf-pce-dste-01.txt |
| | Date: |
23/05/2008 |
| | Authors: |
Siva Sivabalan, Jon Parker, Sami Boutros, Kenji Kumaki |
| | Working Group: |
Path Computation Element (pce) |
| | Formats: |
txt |
|
This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). |
| | Requirements for Management of Overload in the Session Initiation Protocol |
| |
|
Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. |
22/05/2008
| |
|
| |
| | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. |
| | RTP Payload Format for H.264 RCDO Video |
| |
|
This memo describes an RTP Payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RTP Payload format is based on the description in RFC 3984. |
| | Capabilities Advertisement with BGP-4 |
| |
|
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. |
| | DHCP Options for Home Information Discovery in MIPv6 |
| |
| | draft-ietf-mip6-hiopt-17.txt |
| | Date: |
22/05/2008 |
| | Authors: |
Hee-Jin Jang, Alper Yegin, Kuntal Chowdhury, JinHyeock Choi |
| | Working Group: |
Mobility for IPv6 (mip6) |
| | Formats: |
txt |
|
This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. |
| | IPv4 Support for Proxy Mobile IPv6 |
| |
|
This document specifies extensions to Proxy Mobile IPv6 protocol for supporting IPv4 protocol. The scope of this IPv4 support includes the support for the mobile node's IPv4 home address mobility and for allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport. |
| | The ARK Persistent Identifier Scheme |
| |
| | draft-kunze-ark-15.txt |
| | Date: |
22/05/2008 |
| | Authors: |
John Kunze, Richard Rodgers |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [http://NMAH/]ark:/NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending a single question mark (`?'), returns a brief metadata record that is both human- and machine- readable. When the ARK is inflected by appending dual question marks (`??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. |
| | Carrying Attached Addresses in IS-IS |
| |
| | draft-ward-l2isis-03.txt |
| | Date: |
22/05/2008 |
| | Authors: |
David Ward, Radia Perlman, Russ White, Dino Farinacci, Ayan Banerjee |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft specifies the IS-IS extensions necessary to support multi- link IPv4 and IPv6 networks, as well as to provide true link state routing to any protocols running directly over layer 2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used.1. Overview There are a number of systems (for example, [RBRIDGES]) which have proposed using layer 2 addresses carried in a link state routing protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing in specific environments. This draft proposes a set of TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU types, to support these proposed systems. This draft does not propose new forwarding mechanisms using this additional information carried within IS-IS. There is a short section included on two possible ways to build a shortest path first tree including this information, to illustrate how this information might be used. |
| | Common YANG Data Types |
| |
|
This document introduces a collection of common data types to be used with the YANG data modeling language. |
| | Textual Conventions for Syslog Management |
| |
|
This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. |
21/05/2008
| |
|
| |
| | CAPWAP Protocol Base MIB |
| |
| | draft-ietf-capwap-base-mib-00.txt |
| | Date: |
21/05/2008 |
| | Authors: |
Yang Shi, David Perkins, Chris Elliott, Puneet Agarwal |
| | Working Group: |
Control And Provisioning of Wireless Access Points (capwap) |
| | Formats: |
txt |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. |
| | IANA Registration of Experimental and Trial Enumservices (X-Enumservices) |
| |
|
This document specifies a new IANA registry for experimental and trial Enumservices (X-Enumservices), describes corresponding registration procedures, and provides a guideline for creating X-Enumservices and its Registration Documents. |
| | Locating Mobility Servers using DNS |
| |
|
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide Mobility Services. Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [1]. |
| | Extensions to the IODEF-Document Class for Phishing,Fraud,and Other Crimeware |
| |
|
This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. The extensions defined in this document are used to generate two different types of reports: a fraud and phishing report and a wide- spread spam report. Although similar in structure, each report has different required objects and intents.RFC 2129 Keywords |
| | Common Architecture Label IPv6 Security Option (CALIPSO) |
| |
|
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level secure (MLS) networking environments that are both trusted and trustworthy. |
| | One-way Passive Measurement of End-to-End Quality |
| |
| | draft-kikuchi-passive-measure-02.txt |
| | Date: |
21/05/2008 |
| | Authors: |
Yutaka Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, Nobuo Ogashiwa |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft describes a passive measurement method for one-way end-to- end quality. This method reports both whether a flow of packets is in-sequence or not and error types on detecting out-of-sequence. The method consumes small resource therefore it can be adapted to many protocols that have sequence number field. |
| | RFC Editor Proposal for Handling RFC Errata |
| |
|
This document describes a web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the book-keeping for handling errata. |
| | A Reliable Transport Mechanism for PIM |
| |
| | draft-farinacci-pim-port-01.txt |
| | Date: |
21/05/2008 |
| | Authors: |
Dino Farinacci, IJsbrand Wijnands, Apoorva Karan, A Boers, Maria Napierala |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. |
| | Double Flux Defense in the DNS Protocol |
| |
|
The memo provides information and suggests processes for developers of applications based on the DNS protocol and for administrators of servers and networks. It suggests new procedures for DNS and DNSSEC implementations that would prevent abuse of the DNS protocol such as those seen by "Double Flux" service networks. Specifically, this document recommends that all resource records for NS records with Time-To-Live (TTL) settings under 24 hours be dropped as potentially malicious records designed to attack users. This document would update RFCs 1123, 1912, 2181 and 2535. |
| | An Alternative Connection Model for the Message Session Relay Protocol (MSRP) |
| |
|
This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976, in that it uses SDP in a more conventional way when it comes to conveying endpoint address information, and also uses mainstream mechanisms for NAT traversal instead of using MSRP relays. |
| | A Uniform Resource Identifier for Geographic Locations ('geo' URI) |
| |
|
This document specifies an Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI provides latitude, longitude and optionally altitude of a physical location in a compact, simple, human-readable, and protocol independent way. |
| | IP Flow Information Accounting and Export Benchmarking Methodology |
| |
| |