Document Action: 'TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework' to Informational RFC (draft-ietf-trill-directory-framework-07.txt)
The IESG has approved the following document: - 'TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework' (draft-ietf-trill-directory-framework-07.txt) as Informational RFC This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-trill-directory-framework/ Technical Summary: This document contains a brief overview of difficulties cause by multi-destination local network traffic, such as unicast frames where the location of the destination is unknown or ARP/ND packets, and a generic description of how to reduce such difficulties through the use of push and/or pull directories. Data Centers are frequently orchestrated by management software that maintains a directory of the applications, Virtual Machines, IP and MAC addresses in use and the switches to which they are attached. This makes directory assistance to edge switches a reasonable strategy for that case. Working Group Summary: The WG Last Call reviewers of this document include David Black, Sam Aldrin, Erik Nordmark, and Yizhou Li. Some of their comments suggested the removal of material not directly related to the main topic of the document as well as other improvements. Those suggestions were generally adopted. No parts of the draft were particularly contentious. Document Quality: The document is of good quality. David Black's review was particularly helpful and is very much appreciated. Personnel: Document Shepherd: Jon Hudson Responsible Area Director: Ted Lemon RFC Editor Note Please change the title of this document to "Directory Assistance Problem and High Level Design Proposal". This addresses a concern about the title raised by Stewart Bryant.
Document Action: 'IPv6 for 3GPP Cellular Hosts' to Informational RFC (draft-ietf-v6ops-rfc3316bis-06.txt)
The IESG has approved the following document: - 'IPv6 for 3GPP Cellular Hosts' (draft-ietf-v6ops-rfc3316bis-06.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ Technical Summary As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. Working Group Summary IPv6 Operations contains a number of sub-communities, which include operators of various categories, vendors of various categories, academics, researchers, and others. This document, which is intended to replace RFC 3316, was primarily of interest to the vendors of mobile networking equipment, including handsets, cell equipment, and network back ends. It was also reviewed by the Mobile Network operators, including several of the authors of draft-ietf-v6ops-mobile-device-profile, which was developed at the same time. While there were comments and improvements made on the draft, it was not particularly controversial. Document Quality The document is a requirements document describing IPv6 capabilities required in mobile network devices. It is consistent with RFC 3316 an with the Node Requirements. Personnel The Document Shepherd is Fred Baker. The AD is Joel Jaeggli.
Document Action: 'Media Control Channel Framework (CFW) Call Flow Examples' to Informational RFC (draft-ietf-mediactrl-call-flows-13.txt)
The IESG has approved the following document: - 'Media Control Channel Framework (CFW) Call Flow Examples' (draft-ietf-mediactrl-call-flows-13.txt) as Informational RFC This document is the product of the Media Server Control Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows/ Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document presents a series of MEDIACTRL-related call flows, presenting client/server state diagrams, message sequence diagrams, and message contents. It is a reference for the whole MEDIACTRL specification for implementers and protocol researchers alike, and all the flows are modeled from an implementation of the framework and its packages. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Several participants in the WG have advocated a call flows document. The advocates included Jon Peterson, who was the AD at the time the Mediactrl WG was chartered. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Lorenzo Miniero reports that interoperability tests were carried out at IETF73 (Minneapolis, Nov 2008) with implementations from HP (OCMP) and Dialogic testing scenarios illustrated by this document. The minutes report other companies that were planning an implementation at the time: "Stephan notes that implementation is be planned on Broadsoft for the spring. Alan notes that Ditech is also planning an implementation." (http://www.ietf.org/proceedings/73/minutes/mediactrl.htm) As an examples document, the document does not specify any protocol. All the contained examples were produced by running the scenarios using an existing implementation of the MEDIACTRL specification by the authors themselves. A thorough review was done by Dale Worley, who helped tackle some relevant inconsistencies in the presented scenarios. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Dale Worley. The Responsible Area Director is Richard Barnes.
Document Action: 'Per-Interface MIP Addressing Requirements and Design Considerations' to Informational RFC (draft-ietf-mpls-tp-mip-mep-map-09.txt)
The IESG has approved the following document: - 'Per-Interface MIP Addressing Requirements and Design Considerations' (draft-ietf-mpls-tp-mip-mep-map-09.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/ Technical Summary The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. Working Group Summary This document has support in the working group and has been well reviewed. There has been a comparatively long discussion that in the end converged on a widely accepted definition of pre-interface MIPs and MEPs. Document Quality This an informational document, it discusses deployment of per- interface MIPs and MEPs. The document have had the review that is needed. No need for third party expert reviews. Personnel Loa Andersson is the document shepherd. Stewart Bryant is the responsible AD. RFC Editor Note OLD Deployments are strongly advised to use such mechanisms. NEW Deployments are therefore strongly advised to follow the security advice provided in RFC6371 and RFC6941. END
Protocol Action: 'SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol' to Proposed Standard (draft-ietf-tsvwg-sctp-sack-immediately-04.txt)
The IESG has approved the following document: - 'SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol' (draft-ietf-tsvwg-sctp-sack-immediately-04.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately/ Technical Summary This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. It is done by specifying a bit in the DATA chunk header, called the I-bit, which can get set either by the SCTP implementation or by the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. Working Group Summary There was consensus to adopt this as a WG document, review by the WG, and agreement by the WG to finally publish this. Document Quality This document is seen as ready to publish. FreeBSD supports this extension since FreeBSD 7.2, released May 2009. The Linux kernel supports it also (accessibility by the user was added recently to netinet/sctp.h). Personnel The document shepherd is: Gorry Fairhurst, . The responsible AD is: Spencer Dawkins
Document Action: 'Public IPv4 over IPv6 Access Network' to Informational RFC (draft-ietf-softwire-public-4over6-10.txt)
The IESG has approved the following document: - 'Public IPv4 over IPv6 Access Network' (draft-ietf-softwire-public-4over6-10.txt) as Informational RFC This document is the product of the Softwires Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ Technical Summary: This document proposes a mechanism for hosts or customer networks in an IPv6 access network to build bidirectional IPv4 communication with the other IPv4 hosts on the Internet. The mechanism follows the hub and spokes softwire model, and uses an IPv4-over-IPv6 tunnel as a basic method to traverse IPv6 network. Working Group Summary: The working group had active discussion on the draft and the current text of the draft is representative of the consensus of the working group. One of the major issues that was raised during the discussions was that the scheme proposed in the document overlaps with the standards track solution described in the unified CPE draft. The document was then rewritten as Informational to serve as a record of a deployed solution rather than tring to define an alternative solution. Document Quality: The document has received adequate review. The Document Shepherd has no concerns about the depth or breadth of these reviews. There are several implementations of the scheme described in the document and they have been deployed in educational networks across China. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Suresh Krishnan is the document shepherd. Ted Lemon is the responsible AD.
Code Sprint in Vancouver
We will once again have a Code Sprint in Vancouver prior to IETF-88. Please support the tools team with your time and expertise! Or come and build the feature that you always wanted to have :-) When: Saturday, November 2nd, 2013, beginning at 9:30 AM and running until 6 PM Where: The IETF meeting hotel (Hyatt Regency) in Vancouver What: A bunch of hackers get together to work on code for the IETF data tracker, web site and other tools. Some people may be working on improvements in existing functionality, others may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Henrik and Robert will be coordinating the efforts. Please support the tools development effort, join the volunteer team and contribute! The wiki for the sprint, along with a sign-up sheet, is at http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF88Sprint Jari Arkko IETF Chair
Last Call: (Recommendations on filtering of IPv4 packets containing IPv4 options.) to Best Current Practice
The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Recommendations on filtering of IPv4 packets containing IPv4 options.' as Best Current Practice 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-09-30. 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 provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/ballot/ No IPR declarations have been submitted directly on this I-D.
IETF Mentor Program
All, Based on the positive feedback we received after IETF 87, we are going to continue the trial of an IETF mentoring program in Vancouver. During this trial period, we would like to pair newcomers (people who have attended 3 or fewer meetings or have registered as students) with existing IETF participants. The goal is to provide a resource for the newcomer who can assist them with integrating into the IETF community. Mentors and newcomers will be paired prior to IETF 88. What we need is for people to volunteer to be mentors. As a mentor, we would ask that you be willing to assist your mentoring participant before, during, and (hopefully) after IETF 88. The actual level of interaction will be driven by an agreement between the mentor and the mentoring participant. Feedback from IETF 87 indicated that the average amount of time a mentor spent on the program was approximately 4 hours over the entire week. Additionally, we would need a brief description of your areas of expertise, technical interests, and conversational languages. A description of the Mentor Program (including a FAQ describing how to volunteer to be a mentor) is available: http://www.ietf.org/resources/mentoring-program.html. Anyone interested in being a mentor should follow the sign-up instructions contained in the above URL. The more volunteers we have, the stronger the program will be! Regards, IETF Chair
Last Call: (Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)) to Exper
The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)' as Experimental RFC 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-09-30. 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 is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC
The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Using the IPv6 Flow Label for Server Load Balancing' as Informational RFC 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-09-30. 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 describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (An extension to RELOAD to support Direct Response Routing) to Proposed Standard
The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'An extension to RELOAD to support Direct Response Routing' 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-09-30. 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 proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential cases where this extension can be used. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-p2psip-drr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-p2psip-drr/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (An extension to RELOAD to support Relay Peer Routing) to Proposed Standard
The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'An extension to RELOAD to support Relay Peer Routing' 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-09-30. 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 proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential use cases where this extension can be used. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1685/
