Document Action: 'Architectural Guidelines for Multipath TCP Development' to Informational RFC (draft-ietf-mptcp-architecture-05.txt)
The IESG has approved the following document: - 'Architectural Guidelines for Multipath TCP Development' (draft-ietf-mptcp-architecture-05.txt) as an Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/ Technical Summary Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP protocol. This document lists certain high level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. Working Group Summary This is a product of the MPTCP WG. There is a consensus in the WG for publication as an informational RFC. There is a very solid WG consensus behind the document. It captures the key high-level design decisions about the MPTCP protocol, which have been reached after extensive discussion and agreement at the IETF meetings and on the list. Document Quality There is already an implementation of the protocol (draft-ietf- mptcp-multiaddressed) that implements the architecture and high-level design decisions in this document, https://scm.info.ucl.ac.be/trac/mptcp/wiki. There were five detailed reviews of versions of the document. No substantial issues were raised. Expert reviews (MIB doctor etc) were not applicable. Personnel Philip Eardley (philip.eard...@bt.com) is the Document Shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses' to Informational RFC (draft-ietf-mptcp-threat-08.txt)
The IESG has approved the following document: - 'Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses' (draft-ietf-mptcp-threat-08.txt) as an Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-threat/ Technical Summary This document describes the threat analysis for Multi-path TCP which allows an endpoint to use multiple IP addresses to exchange data. The goal of this document is to provide the information of possible threats in Multi-path TCP and recommendable solutions to make MPTCP as secure as the current TCP. The information on this document is important for the basic design of MPTCP protocol. Additional strong secure mechanisms are out-of-scope of this document and will be addressed by other documents. Working Group Summary This draft has been discussed in all IETF meetings since the creation of the WG. There is a strong consensus in the WG for publication as an informational RFC. Document Quality This document was reviewed by various people and has been through WGLC successfully. The MPTCP protocol has been designed based on the recommendations in this document. Personnel Yoshifumi Nishida (nish...@sfc.wide.ad.jp) is the document shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-rmt-bb-fec-raptorq-04.txt (RaptorQ Forward Error Correction Scheme for Object Delivery) to Proposed Standard
The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'RaptorQ Forward Error Correction Scheme for Object Delivery' draft-ietf-rmt-bb-fec-raptorq-04.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 2011-02-09. 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://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ The following IPR Declarations may be related to this I-D: /ipr/615/ /ipr/618/ /ipr/702/ /ipr/734/ /ipr/1292/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'URI Scheme for Java(tm) Message Service 1.0' to Informational RFC (draft-merrick-jms-uri-12.txt)
The IESG has approved the following document: - 'URI Scheme for Java(tm) Message Service 1.0' (draft-merrick-jms-uri-12.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-merrick-jms-uri/ Technical Summary This document defines the format of Uniform Resource Identifiers (URI) as defined in [RFC3986], for designating connections and destination addresses used in the Java Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS destination. The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it. Working Group Summary This is not a WG document. Document Quality The document had 2 reviews from the Apps Review team and most of the comments were addressed, although reviewers have disagreed with authors on some philosophical points. The document was also discussed on the uri-rev...@ietf.org mailing list. Several vendors are planning to implement this specification. Personnel Alexey Melnikov is the Responsible Area Director. RFC Editor Note Please replace the 3rd paragraph of Section 9.2.3 with the following 2 paragraphs: OLD: JMS URI variant registrations cannot be deleted; mechanisms that are no longer believed appropriate for use can be marked as obsolete in the Comment field. NEW: JMS URI variant registrations MUST NOT be deleted; mechanisms that are no longer believed appropriate for use can be marked as obsolete in the Comment field. In exceptional circumstances IESG can reassign responsibility for a JMS URI variant. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
