FECFRAME Working Group Interim Meeting, October 20-22, 2008, San Jose, CA
The FECFrame working group will be having an interim meeting next month in San Jose, California. The agenda will be assembled and sent in a follow-up message. Starting 1200 Oct 20 - 1700 Oct 22 Location: Cisco Systems, San Jose, CA Cisco San Jose, Building 16 http://maps.google.com/maps/ms?client=firefox-ahl=enie=UTF8msa=0msid=109496039069852425144.0112df60cca861566ll=37.409233,-121.926205spn=0.031668,0.028968t=hz=15 Mon, Oct 20th Rm. Honolua Bay, 3rd floor 1200-1700 Tues, Oct 21st Rm. Surfside Jetty, 2nd floor 0900-1700 Wed, Oct 22nd Rm. Uluwatu, 2nd floor 0900-1700 Local hotel options: http://maps.google.com/maps?f=qhl=engeocode=q=hotelsll=37.409233,-121.926205sspn=0.031668,0.028968ie=UTF8ll=37.416527,-121.922193spn=0.031665,0.028968t=hz=15 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5325 on Licklider Transmission Protocol - Motivation
A new Request for Comments is now available in online RFC libraries. RFC 5325 Title: Licklider Transmission Protocol - Motivation Author: S. Burleigh, M. Ramadas, S. Farrell Status: Informational Date: September 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 23 Characters: 57016 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-ltp-motivation-07.txt URL:http://www.rfc-editor.org/rfc/rfc5325.txt This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting long-haul reliable transmission in interplanetary space, but it has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community. This document is a product of the IRTF 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5326 on Licklider Transmission Protocol - Specification
A new Request for Comments is now available in online RFC libraries. RFC 5326 Title: Licklider Transmission Protocol - Specification Author: M. Ramadas, S. Burleigh, S. Farrell Status: Experimental Date: September 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 54 Characters: 120567 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-ltp-10.txt URL:http://www.rfc-editor.org/rfc/rfc5326.txt This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting long-haul reliable transmission in interplanetary space, but it has applications in other environments as well. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community. This document is a product of the IRTF Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5327 on Licklider Transmission Protocol - Security Extensions
A new Request for Comments is now available in online RFC libraries. RFC 5327 Title: Licklider Transmission Protocol - Security Extensions Author: S. Farrell, M. Ramadas, S. Burleigh Status: Experimental Date: September 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 11 Characters: 23269 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-ltp-extensions-08.txt URL:http://www.rfc-editor.org/rfc/rfc5327.txt The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community. This document is a product of the IRTF Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5329 on Traffic Engineering Extensions to OSPF Version 3
A new Request for Comments is now available in online RFC libraries. RFC 5329 Title: Traffic Engineering Extensions to OSPF Version 3 Author: K. Ishiguro, V. Manral, A. Davey, A. Lindem, Ed. Status: Standards Track Date: September 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 25864 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ospf-ospfv3-traffic-13.txt URL:http://www.rfc-editor.org/rfc/rfc5329.txt This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5350 on IANA Considerations for the IPv4 and IPv6 Router Alert Options
A new Request for Comments is now available in online RFC libraries. RFC 5350 Title: IANA Considerations for the IPv4 and IPv6 Router Alert Options Author: J. Manner, A. McDonald Status: Standards Track Date: September 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 8 Characters: 17812 Updates:RFC2113, RFC3175 I-D Tag:draft-manner-router-alert-iana-03.txt URL:http://www.rfc-editor.org/rfc/rfc5350.txt This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS TRACK] 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Softwires (softwire)
A modified charter has been submitted for the Softwires 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 ([EMAIL PROTECTED]) by Tuesday, September 23, 2008. Softwires (softwire) -- Last Modified: 2008-09-10 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/softwire Chair(s): Alain Durand [EMAIL PROTECTED] David Ward [EMAIL PROTECTED] Internet Area Director(s): Jari Arkko [EMAIL PROTECTED] Mark Townsley [EMAIL PROTECTED] Internet Area Advisor: Mark Townsley [EMAIL PROTECTED] Technical Advisor(s): Xing Li [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: With a subject line: subscribe Archive: http://www.ietf.org/mail-archive/web/softwires/current/index.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for, Hubs and Spokes and Mesh. In the former case, hosts or stub networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The focus of this WG is to: Document the softwire encapsulation and control protocol usage for one Address Family (IPv6 or IPv4) over another within the defined problem spaces set out in RFC 4925. Define Dual-Stack Lite which uses softwires and IPv4 NAT functions to reduce the amount of Global and RFC 1918 Local IPv4 addressing necessary for a Service Provider with an IPv6-enabled network to continue delivering IPv4 reachability to its customers. The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base SOFTWIRE encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this group will be reviewed jointly with the DHC WG. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc) . Goals and Milestones: Done Submit a softwires problem statement to the IESG to be considered as an Informational RFC Nov 2008 Submit HS softwire encapsulation and control protocol to the IESG to be considered as a Proposed Standard Nov 2008 Submit Mesh softwire encapsulation and control protocol to the IESG to be considered as a Proposed Standard Mar 2009 Submit dual-stack lite to the IESG to be considered as a Proposed Standard. The initial basis for this solution is described in draft-durand-dual-stack-lite-00.txt and draft-droms-softwires-snat-01.txt. Dec 2009 Submit softwires MIB to the IESG to be considered as Proposed Standard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5343 on Simple Network Management Protocol (SNMP) Context EngineID Discovery
A new Request for Comments is now available in online RFC libraries. RFC 5343 Title: Simple Network Management Protocol (SNMP) Context EngineID Discovery Author: J. Schoenwaelder Status: Standards Track Date: September 2008 Mailbox:[EMAIL PROTECTED] Pages: 9 Characters: 19938 Updates:RFC3411 I-D Tag:draft-ietf-opsawg-snmp-engineid-discovery-03.txt URL:http://www.rfc-editor.org/rfc/rfc5343.txt The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. This document updates RFC 3411. [STANDARDS TRACK] This document is a product of the Operations and Management Area Working Group 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
