| |
| RFC 5701 | IPv6 Address Specific BGP Extended Community Attribute |
| |
| Authors: | Y. Rekhter. |
| Date: | November 2009 |
| Formats: | txt |
| Status: | PROPOSED STANDARD |
|
Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support anIPv6 Address Specific Extended Community. The lack of an IPv6Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address SpecificExtended Community, that addresses this problem. The IPv6 AddressSpecific Extended Community is similar to the IPv4 Address SpecificExtended Community, except that it carries an IPv6 address rather than an IPv4 address. |
|
| |
| RFC 5702 | Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | J. Jansen. |
| Date: | October 2009 |
| Formats: | txt |
| Status: | PROPOSED STANDARD |
|
This document describes how to produce RSA/SHA-256 and RSA/SHA-512DNSKEY and RRSIG resource records for use in the Domain Name SystemSecurity Extensions (RFC 4033, RFC 4034, and RFC 4035). |
|
| |
| RFC 5703 | Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure |
| |
| Authors: | T. Hansen, C. Daboo. |
| Date: | October 2009 |
| Formats: | txt |
| Status: | PROPOSED STANDARD |
|
This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. |
|
| |
| RFC 5704 | Uncoordinated Protocol Development Considered Harmful |
| |
| Authors: | S. Bryant, Ed., M. Morrow, Ed., IAB. |
| Date: | November 2009 |
| Formats: | txt |
| Status: | INFORMATIONAL |
|
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.
This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team onMPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETFRFCs.
Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. |
|
| |
| RFC 5706 | Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions |
| |
| Authors: | D. Harrington. |
| Date: | November 2009 |
| Formats: | txt |
| Status: | INFORMATIONAL |
|
New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal.The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. |
|
| |
| RFC 5709 | OSPFv2 HMAC-SHA Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. |
| Date: | October 2009 |
| Formats: | txt |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
|
This document describes how the National Institute of Standards andTechnology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. |
|
| |
| RFC 5730 | Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. |
|
| |
| RFC 5731 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 4931. |
|
| |
| RFC 5732 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 4932. |
|
| |
| RFC 5733 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. |
|
| |
| RFC 5734 | Extensible Provisioning Protocol (EPP) Transport over TCP |
| |
|
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 4934. |
|
