Last Call: draft-gould-rfc4310bis (Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) ' draft-gould-rfc4310bis-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-02-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19451rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Home Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC
The IESG has approved the following document: - 'Home Automation Routing Requirements in Low Power and Lossy Networks ' draft-ietf-roll-home-routing-reqs-11.txt as an Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-11.txt Technical Summary This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Basic home control modules such as wall switches and plug-in modules may be turned into an advanced home automation solution via the use of an IP-enabled application responding to events generated by wall switches, motion sensors, light sensors, rain sensors, and so on. Network nodes may be sensors and actuators at the same time. An example is a wall switch for replacement in existing buildings. The push buttons may generate events for a controller node or for activating other actuator nodes. At the same time, a built-in relay may act as actuator for a controller or other remote sensors. Because ROLL nodes only cover a limited radio range, routing is often required. These devices are usually highly constrained in term of resources such as battery and memory and operate in unstable environments. Persons moving around in a house, opening or closing a door or starting a microwave oven affect the reception of weak radio signals. Reflection and absorption may cause a reliable radio link to turn unreliable for a period of time and then being reusable again, thus the term lossy. Unlike other categories of PANs, the connected home area is very much consumer-oriented. The implication on network nodes is that devices are very cost sensitive, which leads to resource- constrained environments having slow CPUs and small memory footprints. At the same time, nodes have to be physically small which puts a limit to the physical size of the battery; and thus, the battery capacity. As a result, it is common for low-power sensor-style nodes to shut down radio and CPU resources for most of the time. The radio tends to use the same power for listening as for transmitting Section 2 describes a few typical use cases for home automation applications. Section 3 discusses the routing requirements for networks comprising such constrained devices in a home network environment. These requirements may be overlapping requirements derived from other application-specific routing requirements. A full list of requirements documents may be found in the end of the document. Working Group Summary No controversy. Document Quality The I-D is informational and specifies routing requirements Personnel JP Vasseur (j...@cisco.com) is the Document Shepherd. Adrian Farrel (adrian.far...@huawei.com) is the Responsible AD. RFC Editor Note Section 1 ADD new paragraph before the paragraph beginning Section 2 describes a few... Although this document focuses its text on radio-based wireless networks, home automation networks may also operate using a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. Many such low power link technologies share similar characteristics with low power wireless and this document should be regarded as applying equally to all such links. --- Section 3.3 OLD Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home automation network in a fully populated smart home. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol MUST support 250 devices in the network. NEW Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of devices may form a home automation network in a fully populated smart home, and a large proportion of those may be low power devices. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol needs to be able to support a basic home deployment and so MUST be able to support at least 250 devices in the network. Furthermore,
RFC 5662 on Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5662 on Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:07:27 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5662 Title: Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description Author: S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed. Status: Standards Track Date: January 2010 Mailbox:shep...@storspeed.com, m...@eisler.com, dnov...@netapp.com Pages: 73 Characters: 126581 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-minorversion1-dot-x-12.txt URL:http://www.rfc-editor.org/rfc/rfc5662.txt This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5663 on Parallel NFS (pNFS) Block/Volume Layout
- Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5663 on Parallel NFS (pNFS) Block/Volume Layout From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:07:38 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5663 Title: Parallel NFS (pNFS) Block/Volume Layout Author: D. Black, S. Fridella, J. Glasgow Status: Standards Track Date: January 2010 Mailbox:black_da...@emc.com, ste...@nasuni.com, jglas...@aya.yale.edu Pages: 28 Characters: 68571 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-pnfs-block-12.txt URL:http://www.rfc-editor.org/rfc/rfc5663.txt Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5664 on Object-Based Parallel NFS (pNFS) Operations
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5664 on Object-Based Parallel NFS (pNFS) Operations From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:07:50 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5664 Title: Object-Based Parallel NFS (pNFS) Operations Author: B. Halevy, B. Welch, J. Zelenka Status: Standards Track Date: January 2010 Mailbox:bhal...@panasas.com, we...@panasas.com, j...@panasas.com Pages: 35 Characters: 78200 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-pnfs-obj-12.txt URL:http://www.rfc-editor.org/rfc/rfc5664.txt Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5665 on IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5665 on IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:08:01 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5665 Title: IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats Author: M. Eisler Status: Standards Track Date: January 2010 Mailbox:m...@eisler.com Pages: 14 Characters: 28706 Updates:RFC1833 I-D Tag:draft-ietf-nfsv4-rpc-netid-06.txt URL:http://www.rfc-editor.org/rfc/rfc5665.txt This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5666 on Remote Direct Memory Access Transport for Remote Procedure Call
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - Delivered-To: rfc-edi...@rfc-editor.org To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5666 on Remote Direct Memory Access Transport for Remote Procedure Call From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:08:16 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5666 Title: Remote Direct Memory Access Transport for Remote Procedure Call Author: T. Talpey, B. Callaghan Status: Standards Track Date: January 2010 Mailbox:tmtal...@gmail.com, bre...@apple.com Pages: 34 Characters: 83728 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-rpcrdma-09.txt URL:http://www.rfc-editor.org/rfc/rfc5666.txt This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5667 on Network File System (NFS) Direct Data Placement
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5667 on Network File System (NFS) Direct Data Placement From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:08:28 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5667 Title: Network File System (NFS) Direct Data Placement Author: T. Talpey, B. Callaghan Status: Standards Track Date: January 2010 Mailbox:tmtal...@gmail.com, bre...@apple.com Pages: 10 Characters: 83728 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-nfsdirect-08.txt URL:http://www.rfc-editor.org/rfc/rfc5667.txt This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5716 on Requirements for Federated File Systems
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5716 on Requirements for Federated File Systems From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:08:40 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5716 Title: Requirements for Federated File Systems Author: J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik Status: Informational Date: January 2010 Mailbox:jlent...@netapp.com, everh...@netapp.com, dell...@bbn.com, tewa...@us.ibm.com, ma...@almaden.ibm.com Pages: 26 Characters: 58051 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-federated-fs-reqts-06.txt URL:http://www.rfc-editor.org/rfc/rfc5716.txt This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Network File System Version 4 Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5710 on PathErr Message Triggered MPLS and GMPLS LSP Reroutes
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5710 on PathErr Message Triggered MPLS and GMPLS LSP Reroutes From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, m...@ietf.org Date: Thu, 14 Jan 2010 23:08:51 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5710 Title: PathErr Message Triggered MPLS and GMPLS LSP Reroutes Author: L. Berger, D. Papadimitriou, JP. Vasseur Status: Standards Track Date: January 2010 Mailbox:lber...@labn.net, dimitri.papadimitr...@alcatel-lucent.be, j...@cisco.com Pages: 12 Characters: 27233 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-gmpls-lsp-reroute-06.txt URL:http://www.rfc-editor.org/rfc/rfc5710.txt This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5711 on Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5711 on Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, m...@ietf.org Date: Thu, 14 Jan 2010 23:09:03 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5711 Title: Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages Author: JP. Vasseur, Ed., G. Swallow, I. Minei Status: Standards Track Date: January 2010 Mailbox:j...@cisco.com, swal...@cisco.com, i...@juniper.net Pages: 7 Characters: 12596 Updates:RFC3209 I-D Tag:draft-ietf-mpls-3209-patherr-06.txt URL:http://www.rfc-editor.org/rfc/rfc5711.txt The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5712 on MPLS Traffic Engineering Soft Preemption
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5712 on MPLS Traffic Engineering Soft Preemption From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, m...@ietf.org Date: Thu, 14 Jan 2010 23:09:15 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5712 Title: MPLS Traffic Engineering Soft Preemption Author: M. Meyer, Ed., JP. Vasseur, Ed. Status: Standards Track Date: January 2010 Mailbox:matthew.me...@bt.com, j...@cisco.com Pages: 13 Characters: 27371 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-soft-preemption-18.txt URL:http://www.rfc-editor.org/rfc/rfc5712.txt This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5713 on Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5713 on Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, a...@ietf.org Date: Thu, 14 Jan 2010 23:09:32 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5713 Title: Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author: H. Moustafa, H. Tschofenig, S. De Cnodder Status: Informational Date: January 2010 Mailbox:hassnaa.moust...@orange-ftgroup.com, hannes.tschofe...@gmx.net, stefaan.de_cnod...@alcatel-lucent.com Pages: 18 Characters: 39600 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ancp-security-threats-08.txt URL:http://www.rfc-editor.org/rfc/rfc5713.txt The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS. This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Access Node Control Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5714 on IP Fast Reroute Framework
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5714 on IP Fast Reroute Framework From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, rt...@ietf.org Date: Thu, 14 Jan 2010 23:09:45 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5714 Title: IP Fast Reroute Framework Author: M. Shand, S. Bryant Status: Informational Date: January 2010 Mailbox:msh...@cisco.com, stbry...@cisco.com Pages: 15 Characters: 32854 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rtgwg-ipfrr-framework-13.txt URL:http://www.rfc-editor.org/rfc/rfc5714.txt This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Routing Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5715 on A Framework for Loop-Free Convergence
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5715 on A Framework for Loop-Free Convergence From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, rt...@ietf.org Date: Thu, 14 Jan 2010 23:09:56 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5715 Title: A Framework for Loop-Free Convergence Author: M. Shand, S. Bryant Status: Informational Date: January 2010 Mailbox:msh...@cisco.com, stbry...@cisco.com Pages: 22 Characters: 53223 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rtgwg-lf-conv-frmwk-07.txt URL:http://www.rfc-editor.org/rfc/rfc5715.txt A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Routing Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 153, RFC 5735 on Special Use IPv4 Addresses
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: BCP 153, RFC 5735 on Special Use IPv4 Addresses From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, i...@iana.org Date: Thu, 14 Jan 2010 23:10:08 -0800 (PST) A new Request for Comments is now available in online RFC libraries. BCP 153 RFC 5735 Title: Special Use IPv4 Addresses Author: M. Cotton, L. Vegoda Status: Best Current Practice Date: January 2010 Mailbox:michelle.cot...@icann.org, leo.veg...@icann.org Pages: 10 Characters: 20369 Obsoletes: RFC3330 See Also: BCP0153 I-D Tag:draft-iana-rfc3330bis-11.txt URL:http://www.rfc-editor.org/rfc/rfc5735.txt This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5736 on IANA IPv4 Special Purpose Address Registry
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5736 on IANA IPv4 Special Purpose Address Registry From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, i...@iana.org Date: Thu, 14 Jan 2010 23:10:19 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5736 Title: IANA IPv4 Special Purpose Address Registry Author: G. Huston, M. Cotton, L. Vegoda Status: Informational Date: January 2010 Mailbox:g...@apnic.net, michelle.cot...@icann.org, leo.veg...@icann.org Pages: 6 Characters: 10823 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iana-special-ipv4-registry-02.txt URL:http://www.rfc-editor.org/rfc/rfc5736.txt This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
DNSEXT WG Virtual Interim Meeting
The DNSEXT WG will hold an Interim meeting by audio on Tuesday, 16th Feb 2010 at 15:00 UTC, New York 10:00, Beijing 23:00, Moscow 18:00. http://www.timeanddate.com/worldclock/fixedtime.html?year=2010month=2day=16hour=15min=0sec=0 Agenda, slides and webex url and conference call dial-in details will be posted to the mailing list and webpage: http://trac.tools.ietf.org/wg/dnsext/trac/wiki/WikiStart Original working group announcement: http://www.psg.com/lists/namedroppers/namedroppers.2010/msg00043.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Mobility Extensions (netext)
A modified charter has been submitted for the Mobility Extensions (netext) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, January 26, 2010. This update of the NETEXT working group's charter involves adding work items related to cross-interface handover and flow mobility that were discussed in the NETEXT2 BOF but not adopted by the IETF. After discussions in the NETEXT WG meeting in Hiroshima, a significantly reduced scope for the work was adopted, and this work is now being added to the charter. In addition, one work item on RADIUS support moves from the NETLMM WG to this WG. The differences to the current charter can be seen at http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html Mobility Extensions (netext) Last Modified: 2010-01-19 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli rkoo...@starentnetworks.com * Basavaraj Patil basavaraj.pa...@nokia.com Internet Area Director(s): * Ralph Droms rdr...@cisco.com * Jari Arkko jari.ar...@piuha.net Internet Area Advisor: * Jari Arkko jari.ar...@piuha.net Mailing Lists: General Discussion: net...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to
