Last Call: (Host address availability recommendations) to Best Current Practice
The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Host address availability recommendations' 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 2016-03-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. Abstract This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions' 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 2016-03-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. Abstract The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This acts as a safety measure to prevent starvation of network resources denying other flows from access to the Internet, such measures are essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP circuit- breakers. Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ballot/ No IPR declarations have been submitted directly on this I-D.
BCP 203, RFC 7803 on Changing the Registration Policy for the NETCONF Capability URNs Registry
A new Request for Comments is now available in online RFC libraries. BCP 203 RFC 7803 Title: Changing the Registration Policy for the NETCONF Capability URNs Registry Author: B. Leiba Status: Best Current Practice Stream: IETF Date: February 2016 Mailbox:barryle...@computer.org Pages: 3 Characters: 5133 Updates:RFC 6241 See Also: BCP 203 I-D Tag:draft-leiba-netmod-regpolicy-update-02.txt URL:https://www.rfc-editor.org/info/rfc7803 DOI:http://dx.doi.org/10.17487/RFC7803 The registration policy for the "Network Configuration Protocol (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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
Last Call: (Additional WebRTC audio codecs for interoperability.) to Informational RFC
The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Additional WebRTC audio codecs for interoperability.' 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 2016-03-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. Abstract To ensure a baseline level of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the most relevant interoperability use cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Audio Codec and Processing Requirements' 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 2016-03-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. Abstract This document outlines the audio codec and processing requirements for WebRTC endpoints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ No IPR declarations have been submitted directly on this I-D.
IETF 95 - Hotel Reservation Deadlines and Meeting Information
IETF 95 in Buenos Aires, Argentina April 3-8, 2016 Meeting Venue: Hilton Buenos Aires Register: http://www.ietf.org/meeting/register.html Important Deadlines & Registration Fees: http://www.ietf.org/meeting/important-dates-2016.html Accommodation Details: http://www.ietf.org/meeting/95/hotel.html 1. Hotel Reservation Deadlines 2. Letters of Invitation 3. Sponsorships Available 4. Hackathon Registration 5. Code Sprint 6. Meeting Wiki 1. Hotel Reservation Deadlines Please note the below reservation deadlines and plan accordingly. a. Hilton Buenos Aires - http://ietf.org/meeting/95/hotel.html#hilton A limited number of rooms are now available at the Hilton Buenos Aires. b. Holiday Inn Express Puerto Madero - http://ietf.org/meeting/95/hotel.html#holidayinn Reservation cutoff: EXTENDED TO FRIDAY, FEBRUARY 26 c. Sheraton Buenos Aires - http://ietf.org/meeting/95/hotel.html#sheraton Reservations cutoff: March 1 d. InterContinental BA - http://ietf.org/meeting/95/hotel.html#intercon Reservations cutoff: March 1 e. Sheraton Libertador - http://ietf.org/meeting/95/hotel.html#sheratonlib Reservations cutoff: March 4 f. NH Florida - http://ietf.org/meeting/95/hotel.html#Florida Reservations cutoff: March 8 (NOTE: Reservations by Phone or email only) g. NH 9 de Julio - http://ietf.org/meeting/95/hotel.html#Julio Reservations cutoff: March 8 (NOTE: Reservations by Phone or email only) h. City Hotel NH - http://ietf.org/meeting/95/hotel.html#City Reservations cutoff: March 8 (NOTE: Reservations by Phone or email only) i. NH Collection Lancaster - http://ietf.org/meeting/95/hotel.html#Lancaster Reservations cutoff: March 8 (NOTE: Reservations by Phone or email only) j. Plaza Hotel Buenos Aires - http://ietf.org/meeting/95/hotel.html#Plaza Reservations cutoff: March 15 2. Letters of Invitation Information regarding visa requirements for Argentina: http://www.migraciones.gov.ar/accesibleingles/?visas Local Letters of Invitation: Letters Requested Prior to February 15th: If you requested a local letter of invitation prior to February 15th, your visa application process does not require a local letter of invitation. You should have received an email detailing the process to secure your visa. If you did not receive this email, please send a message to ietf95-v...@ietf.org. Letters Requested After February 15th: You will need a local letter of invitation from CABASE to process your visa application. The IETF has arranged a visa process for attendees that does not require a hard copy local letter of invitation. The electronic version that you print will be sufficient. Please use the link in your IETF registration confirmation email to request this letter. If you have not yet registered for the meeting, you will be able to generate a letter during the registration process. 3. Sponsorships Available Information about sponsorships for the first-ever IETF meeting in Latin America, during the 30th anniversary of the IETF can be found here: http://iaoc.ietf.org/host-and-sponsorship.html 4. Hackathon Information The Internet Engineering Task Force (IETF) is holding a Hackathon at IETF 95 to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. When: Saturday April 2 and Sunday April 3 Where: Hilton Buenos Aires, Room: TBD Signup for the Hackathon: https://www.ietf.org/registration/ietf95/hackathonregistration.py More information can be found here: http://ietf.org/hackathon/95-hackathon.html Keep up to date by subscribing to: https://www.ietf.org/mailman/listinfo/hackathon The Hackathon is free to attend and open to all. Extend the invitation to colleagues outside the IETF! Here’s what happened at the Hackathon in Yokohama at IETF 94 (blog post): https://communities.cisco.com/community/developer/opensource/blog/2015/11/12/ietf-94-hackathon-open-source-and-open-standards-in-yokohama These brief videos from the IETF 93 Hackathon in Prague explain more about how IETF Hackathons work: https://youtu.be/emZ-pIJLDlg?list=PLC86T-6ZTP5g87jdxNqdWV5475U-yEE8M To see the current list of technologies planned for the IETF 95 Hackathon, or to volunteer to champion additional technologies,
UPDATED Document Action: 'Privacy considerations for DHCPv6' to Informational RFC (draft-ietf-dhc-dhcpv6-privacy-05.txt)
The IESG has approved the following document: - 'Privacy considerations for DHCPv6' (draft-ietf-dhc-dhcpv6-privacy-05.txt) as Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/ Technical Summary: This document describes the privacy issues associated with the use of DHCPv6 (RFC 3315). Working Group Summary: This document analyzes the privacy issues associated with the use of DHCPv6. Document Quality: This document has had thorough reviews by many interested and knowledgeable folks (beyond those mentioned in the acknowledgements section). There were no significant points of difficulty or controversy with the contents of the document. Personnel: Bernie Volz is the document shepherd. Brian Haberman is the responsible AD.
Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures)
This is an announcement of an IETF-wide Call for Comment on draft-iab-rfc3677bis-00. The document is being considered for publication as a Best Current Practice RFC within the IAB stream, and is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-rfc3677bis/ The Call for Comment will last until 2016-03-23. Please send comments to architecture-disc...@ietf.org and i...@iab.org. Abstract This memo, which obsoletes RFC3677, outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.
Protocol Action: 'An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees' to Proposed Standard (draft-ietf-rtgwg-mrt-frr-architecture-10.txt)
The IESG has approved the following document: - 'An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees' (draft-ietf-rtgwg-mrt-frr-architecture-10.txt) as Proposed Standard This document is the product of the Routing Area Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/ Technical Summary This document defines the architecture for IP/LDP Fast-Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. Working Group Summary The WG thoroughly reviewed the document and no outstanding technical issues remain. Both WG Chairs and the AD assigned to this WG are involved in the work, so the Responsible AD (listed below), aided by the Document Shepherd, conducted the WGLC. During this process there were some comments about publishing this document as Informational/Experimental, but there is rough consensus to proceed on the Standards Track. Document Quality There are existing implementations and multiple vendors have shown significant interest in the topic. Personnel Document Shepherd: János Farkas Responsible Area Director: Alvaro Retana RFC Editor Note This document and draft-ietf-rtgwg-mrt-frr-algorithm should be published together (consecutive RFC numbers would be nice, but not necessary).
Protocol Action: 'Anonymity profile for DHCP clients' to Proposed Standard (draft-ietf-dhc-anonymity-profile-08.txt)
The IESG has approved the following document: - 'Anonymity profile for DHCP clients' (draft-ietf-dhc-anonymity-profile-08.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/ Technical Summary: This document specifies an anonymity profile for DHCP clients to remain as anonymous as possible on visited networks. Working Group Summary: This document is an answer to the privacy considerations raised in draft-ietf-dhc-dhcp-privacy and draft-ietf-dhc-dhcpv6-privacy with respect to DHCPv4 and DHCPv6, respectively. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, designed to minimize disclosure of identifying information. Document Quality: This document has had thorough reviews by many interested and knowledgeable folks (beyond those mentioned in the acknowledgements section). There were no significant points of difficulty or controversy with the contents of the document. Microsoft did a prototype implementation and reported great results (see https://www.ietf.org/proceedings/93/slides/slides-93-dhc-1.pdf). Personnel: Bernie Volz is the document shepherd. Brian Haberman is the responsible AD.
Document Action: 'Privacy considerations for DHCPv6' to Informational RFC (draft-ietf-dhc-dhcpv6-privacy-04.txt)
The IESG has approved the following document: - 'Privacy considerations for DHCPv6' (draft-ietf-dhc-dhcpv6-privacy-04.txt) as Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/ Technical Summary: This document describes the privacy issues associated with the use of DHCPv6 (RFC 3315). Working Group Summary: This document analyzes the privacy issues associated with the use of DHCPv6. Document Quality: This document has had thorough reviews by many interested and knowledgeable folks (beyond those mentioned in the acknowledgements section). There were no significant points of difficulty or controversy with the contents of the document. Personnel: Bernie Volz is the document shepherd. Brian Haberman is the responsible AD.
Last Call: (Defining and Using Metadata with YANG) to Proposed Standard
The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Defining and Using Metadata with YANG' 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 2016-03-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. Abstract This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (JSON Encoding of Data Modeled with YANG) to Proposed Standard
The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'JSON Encoding of Data Modeled with YANG' 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 2016-03-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. Abstract This document defines encoding rules for representing configuration, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ballot/ No IPR declarations have been submitted directly on this I-D.
