Protocol Action: 'Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis' to Proposed Standard (draft-ietf-behave-nat64-discovery-heuristic-17.txt)
The IESG has approved the following document: - 'Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis' (draft-ietf-behave-nat64-discovery-heuristic-17.txt) as Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic/ Technical Summary This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. Working Group Summary The document specifies a heuristic that is not perfect and so some points were rough, but the constraint for this document was to operate without changes to code (only configuration) in existing networks. Given that constraint, there was strong consensus. Relaxing the constraint would allow one to do better, and that is the focus of a draft recently submitted to the PCP WG. Document Quality Jouni Korhonen did a prototype implementation that was presented in the WG but not included in commercial product. Additionally, Cameron Byrne (T-Mobile USA) has a 464XLAT implementation that also implements this draft, as noted at https://sites.google.com/site/tmoipv6/464xlat#TOC-Android-CLAT-on-a-UMTS-IPv6-only-network-with-DNS64-NAT64 Personnel Document Shepherd: Dave Thaler (dtha...@microsoft.com) Responsible Area Director: Martin Stiemerling
Document Action: 'Applicability of MPLS-TP Linear Protection for Ring Topologies' to Informational RFC (draft-ietf-mpls-tp-ring-protection-06.txt)
The IESG has approved the following document: - 'Applicability of MPLS-TP Linear Protection for Ring Topologies' (draft-ietf-mpls-tp-ring-protection-06.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ Technical Summary This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to Multi-Protocol Label Switching Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Protection on rings offers a number of opportunities for optimization as the protection choices are starkly limited (all traffic traveling one way around a ring can only be switched to travel the other way on the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied to single ring topologies, discusses how most of the requirements are met, and describes scenarios in which the function provided by applying linear protection in a ring topology falls short of some of the requirements. Working Group Summary This document was the subject of considerable debate in the MPLS working group. There was some concern about whether this work prohibited or devalued the development of specialised protection techniques for deployment in ring topologies. The document was re-worked to make it clear that it is basically an applicability statement showing how linear protection defined in RFC 6378 can be applied to ring topologies, what function can be achieved, and what issues remain. It was made clear to the working group that specialist ring protection techniques were still in scope for the working group provided that they demonstrate improvements over the application of linear protection, and provided they can interwork with general protection in the wider MPLS-TP network. A second WG last call was held and the document gained consensus. Please see RFC editor note for a commentary on the number of front-page authors. Document Quality This an informational document, it describes how the technologies defined in earlier RFCs can be applied to ring topologies. The document has been reviewed needed, the working group last call was brought to the attention of SG15 in ITU-T. Personnel Loa Andersson (l...@pi.nu) is the document shepherd Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note Please allow an exception to the normal front-page limit so that all eight named authors can be present. The WG chair/ shepherd explains it as follows: > Early 2010 we had 5 or 6 different drafts addressing "mpls-tp- > ring-protection" from one aspect or another. Most of these > drafts had 2 or maybe 3 different authors. > > The WG chairs took an initiative to discuss the possibilities to > merge all drafts into one. The discussion was partially > successful, and all draft but one, were merged into a single > document. Texts from all drafts were merged into draft- > weingarten-mpls-tp-ring-protection (later to be adopted as > the working group draft draft-ietf-mpls-tp-ring-protection. > > The number of authors on the first page reflect text > contributions made to the drafts that were merged. --- You may rename and reposition Section 1.4 according to your style guide. --- If (and only if) you consider it necessary, you may consider some of the text as Tables and apply captions as follows... In Section 3.1 on page 19 "Table x : Backup LSPs for Node Protection" In Section 3.1.1 on page 20 "Table x : Nodes Traversed by Protection: LSPs" In Section 3.1.1 on page 21 "Table x : Bandwidth Utilization on Links During Protection" In Section 3.2.2 on page 25 "Table x : Context Specific Labels for Connected LSPs"
Results of IETF-conflict review for draft-touch-tcp-ao-nat-04
The IESG has completed a review of draft-touch-tcp-ao-nat-04 consistent with RFC5742. The IESG has no problem with the publication of 'A TCP Authentication Option NAT Extension' as an Experimental RFC. The IESG has concluded that this work is related to IETF work done in WG TCPM, but this relationship does not prevent publishing. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-touch-tcp-ao-nat/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-touch-tcp-ao-nat/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Results of IETF-conflict review for draft-brandenburg-cdni-has-05
The IESG has completed a review of draft-brandenburg-cdni-has-05 consistent with RFC5742. The IESG has no problem with the publication of 'Models for adaptive-streaming-aware CDN Interconnection' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in WG CDNI, but this relationship does not prevent publishing. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-brandenburg-cdni-has/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-brandenburg-cdni-has/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' as 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 2013-06-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. Abstract 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended Unique Identifiers (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g. ethernet. This document defines two new DNS resource record types, EUI48 and EUI64, for encoding ethernet addresses in the DNS. The file can be obtained via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count metric Reporting) to Proposed Standard
The IESG has received a request from the Metric Blocks for use with RTCP's Extended Report Framework WG (xrblock) to consider the following document: - 'RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count metric Reporting' as 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 2013-06-03. 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. Abstract This document defines an RTP Control Protocol(RTCP) Extended Report (XR) Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-discard/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-discard/ballot/ No IPR declarations have been submitted directly on this I-D.
