RFC 5707 on Media Server Markup Language (MSML)
A new Request for Comments is now available in online RFC libraries. RFC 5707 Title: Media Server Markup Language (MSML) Author: A. Saleem, Y. Xin, G. Sharratt Status: Informational Date: February 2010 Mailbox:adnan.sal...@radisys.com, yong@radisys.com, garland.sharr...@gmail.com Pages: 184 Characters: 376984 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-saleem-msml-09.txt URL:http://www.rfc-editor.org/rfc/rfc5707.txt The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5690 on Adding Acknowledgement Congestion Control to TCP
A new Request for Comments is now available in online RFC libraries. RFC 5690 Title: Adding Acknowledgement Congestion Control to TCP Author: S. Floyd, A. Arcia, D. Ros, J. Iyengar Status: Informational Date: February 2010 Mailbox:fl...@icir.org, ae.ar...@telecom-bretagne.eu, david@telecom-bretagne.eu, jiyen...@fandm.edu Pages: 33 Characters: 83437 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-floyd-tcpm-ackcc-06.txt URL:http://www.rfc-editor.org/rfc/rfc5690.txt This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5684 on Unintended Consequences of NAT Deployments with Overlapping Address Space
A new Request for Comments is now available in online RFC libraries. RFC 5684 Title: Unintended Consequences of NAT Deployments with Overlapping Address Space Author: P. Srisuresh, B. Ford Status: Informational Date: February 2010 Mailbox:srisur...@yahoo.com, bryan.f...@yale.edu Pages: 63018 Characters: 26 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ford-behave-top-07.txt URL:http://www.rfc-editor.org/rfc/rfc5684.txt This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5578 on PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
A new Request for Comments is now available in online RFC libraries. RFC 5578 Title: PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics Author: B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams Status: Informational Date: February 2010 Mailbox:bbe...@cisco.com, sratl...@cisco.com, pd...@cisco.com, timothy.kai...@harris.com, michael.d.ad...@l-3com.com Pages: 24 Characters: 54936 Obsoletes: RFC4938 I-D Tag:draft-bberry-rfc4938bis-00.txt URL:http://www.rfc-editor.org/rfc/rfc5578.txt This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5414 on Wireless LAN Control Protocol (WiCoP)
A new Request for Comments is now available in online RFC libraries. RFC 5414 Title: Wireless LAN Control Protocol (WiCoP) Author: S. Iino, S. Govindan, M. Sugiura, H. Cheng Status: Informational Date: February 2010 Mailbox:iino.sato...@jp.panasonic.com, saravanan.govin...@sg.panasonic.com, sugiura.mikih...@jp.panasonic.com, hong.ch...@sg.panasonic.com Pages: 54 Characters: 118969 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iino-capwap-wicop-02.txt URL:http://www.rfc-editor.org/rfc/rfc5414.txt The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF Outcomes Wiki
The IETF Outcomes wiki is now available on the IETF Tools site for review and enhancement by the community: http://trac.tools.ietf.org/misc/outcomes This wiki lists technologies and services that were developed in the IETF and represent notable successes and failures. The wiki is a collaborative effort of IETF participants, and you are invited to provide feedback to the community about the utility of IETF efforts as well as to facilitate public understanding of IETF work and its impact. The wiki home page offers a charter for the effort. The first activity will be to improve on that charter. The wiki and a compantion mail list will be used for discussion of the charter. The mail list will also be used to discuss the design and content of the wiki. Enjoy, Russ Housley IETF Chair P.S. Thanks to Dave Crocker for the energy to make this wiki materialize. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Revised Guidelines to Authors of Internet-Drafts
An updated version of the Guidelines to Authors of Internet-Drafts is now available and has been posted on the IETF website: http://www.ietf.org/id-info/guidelines.html OR http://www.ietf.org/id-info/1id-guidelines.txt Summary of changes in this version: o Update the references to reflect the current BCPs. Remove the reference to rfc2333bis, which is no longer an active work item. Add a references for the I-D Submission Tool and the Data Tracker. o Rewrite of Section 3. o Structure the choices in Section 4 to match the current BCPs. o Provide two boilerplate options in Section 5, as approved by the IESG on 7 January 2010. o Remove the discussion of grace period from Section 7. With the I-D Submission Tool, there is no longer a need for one. o Include URLs that are not redirected. o Significant editorial changes. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sipping-rtcp-summary (Session Initiation Protocol Event Package for Voice Quality Reporting) to Proposed Standard
The IESG has received a request from the Session Initiation Proposal Investigation WG (sipping) to consider the following document: - 'Session Initiation Protocol Event Package for Voice Quality Reporting ' 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-17. 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-ietf-sipping-rtcp-summary-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14087&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Basic Socket Interface Extensions for Host Identity Protocol (HIP)' to Experimental RFC
The IESG has approved the following document: - 'Basic Socket Interface Extensions for Host Identity Protocol (HIP) ' as an Experimental RFC This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-12.txt Technical Summary This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. Working Group Summary Nothing in the WG process worth mentioning. Document Quality Currently, there are no implementations of this specification but there are plans to implement it. Personnel Gonzalo Camarillo (gonzalo.camari...@ericsson.com) is the document shepherd. Ralph Droms (rdr...@cisco.com) is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-dhcpv6-vendor-message (DHCPv6 Vendor-specific Message) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv6 Vendor-specific Message ' 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-17. 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-ietf-dhc-dhcpv6-vendor-message-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18130&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-dhcpv4-vendor-message (DHCPv4 Vendor-specific Message) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv4 Vendor-specific Message ' 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-17. 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-ietf-dhc-dhcpv4-vendor-message-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18131&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
