|
Internet Drafts - IDs for Mar/2009
Index - Month Index of IDs
All IDs - sorted by date)
30/03/2009
| |
|
| |
| | X.509 Key and Signature Encoding for the KeyNote Trust Management System |
| |
|
This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]). |
27/03/2009
| |
|
| |
| | Expressing SNMP SMI Datatypes in XML Schema Definition Language |
| |
|
This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. |
26/03/2009
| |
|
| |
| | IPv6 Address Specific BGP Extended Communities Attribute |
| |
|
Current specifications of BGP Extended Communities [RFC4360] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. |
24/03/2009
| |
|
| |
| | Container Option for Server Configuration |
| |
|
In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. |
| | A Session Initiation Protocol (SIP) Extension for the Identification of Services |
| |
|
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains, or use in the Internet at large. The document also defines a URN to identify both services and UA applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. |
| | Transmission of IPv4 Packets over ISATAP Interfaces |
| |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. |
09/03/2009
| |
|
| |
| | Design Choices When Expanding DNS |
| |
|
This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. |
| | Connectivity Preconditions for Session Description Protocol Media Streams |
| |
|
This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. |
| | Update for RSAES-OAEP Algorithm Parameters |
| |
| | draft-ietf-pkix-rfc4055-update-02.txt |
| | Date: |
09/03/2009 |
| | Authors: |
Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk |
| | Working Group: |
Public-Key Infrastructure (X.509) (pkix) |
| | Formats: |
txt |
|
This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. |
| | Framework for Establishing an SRTP Security Context using DTLS |
| |
|
This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. |
06/03/2009
| |
|
| |
| | Vendor Specific RADIUS Attributes for the Delivery of Keying Material |
| |
|
This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. |
| | ECC Brainpool Standard Curves and Curve Generation |
| |
|
This Memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). |
05/03/2009
| |
|
| |
| | Multicast in MPLS/BGP IP VPNs |
| |
| | draft-ietf-l3vpn-2547bis-mcast-08.txt |
| | Date: |
05/03/2009 |
| | Authors: |
Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakhov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa |
| | Working Group: |
Layer 3 Virtual Private Networks (l3vpn) |
| | Formats: |
txt |
|
In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. |
| | A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP) |
| |
| | draft-ietf-sipping-cc-framework-11.txt |
| | Date: |
05/03/2009 |
| | Authors: |
Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Dan Petrie, Alan Johnston |
| | Working Group: |
Session Initiation Proposal Investigation (sipping) |
| | Formats: |
txt xml |
|
This document defines a framework and requirements for call control and multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet. |
| | RTCP-XR Summary |
| |
|
This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. |
03/03/2009
| |
|
| |
| | Netnews Architecture and Protocols |
| |
|
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.Internet Draft Comments Comments are solicited and should be addressed to the Usenet Format Working Group at ietf-usefor@imc.org. |
02/03/2009
| |
|
| |
| | ForCES Protocol Specification |
| |
| | draft-ietf-forces-protocol-22.txt |
| | Date: |
02/03/2009 |
| | Authors: |
Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Salim, Hormuzd Khosravi, Weiming Wang |
| | Working Group: |
Forwarding and Control Element Separation (forces) |
| | Formats: |
txt xml |
|
This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).Authors The participants in the ForCES Protocol Team, primary co-authors and co-editors, of this protocol specification, are: Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern who has done extensive editing in support of congruence between the model and this protocol specification. Without his participation and persistence, this specification might never have been completed. |
| | An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework |
| |
|
This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, DTMF collect and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. |
|
