Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard
The IESG has received a request from the Protocol to Access WS database WG (paws) to consider the following document: - 'Protocol to Access White-Space (PAWS) Databases' 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 2014-07-07. 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 Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2203/ http://datatracker.ietf.org/ipr/2340/ http://datatracker.ietf.org/ipr/2239/
Protocol Action: 'UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-mmusic-udptl-dtls-10.txt)
The IESG has approved the following document: - 'UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)' (draft-ietf-mmusic-udptl-dtls-10.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Alissa Cooper and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ Technical Summary The document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). Working Group Summary There has been no controversy on the document. On the contrary in fact with both quick WG interest and adoption as well as review and finalization. Document Quality There are no known implementations of the protocol, however it has been adopted by 3GPP. There are no new Media Types, MIBs, etc. and hence no special reviews. Personnel Flemming Andreasen is the document shepherd. Alissa Cooper is the responsible area director.
Document Action: 'PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths' to Experimental RFC (draft-ietf-pce-pcep-inter-domain-p2mp
The IESG has approved the following document: - 'PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths' (draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08.txt) as Experimental RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-inter-domain-p2mp-procedures/ Technical Summary The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. Working Group Summary No controversy. Two proposals came out as individual submissions and got merged before moving to WG I-D. Document Quality There are existing prototype implementations, but no plans to include the protocol in product. Hence experimental. Personnel Julien Meuric is the Document Shepherd Adrian Farrel is the Responsible Area Director
Protocol Action: 'LDP Hello Cryptographic Authentication' to Proposed Standard (draft-ietf-mpls-ldp-hello-crypto-auth-10.txt)
The IESG has approved the following document: - 'LDP Hello Cryptographic Authentication' (draft-ietf-mpls-ldp-hello-crypto-auth-10.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ Technical Summary This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. Working Group Summary Taking a mostly security document through a working group like MPLS is a bit tricky. Most of the participants do not have there focus on security issues. While a large majority agree that the security work has a huge value, it is often not highest on the priority list for the average MPLS participant. Securing routing protocols, like LDP, started with a analysis done by the KARP working group. KARP pointed to the UDP based Hello messages as a potential risk. The current draft has been developed by the MPLS working group and reviewed by KARP during WGLC. The comments from people active in KARP have been very valuable. Document Quality Currently we do not know of existing implementations of this draft, The SecDir review from Yaron Sheffer took a while to resolve, but has improved the document. Personnel Adrian Farrel is the Responsible AD Loa Andersson is the Document Shepherd.
Document Action: 'Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks' to Informational RFC (draft-ietf-pwe3-p2mp-pw-requirements-10.txt)
The IESG has approved the following document: - 'Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks' (draft-ietf-pwe3-p2mp-pw-requirements-10.txt) as Informational RFC This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-p2mp-pw-requirements/ Technical Summary This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point- to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to-Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service) as defined in the Layer 2 Virtual Private Network Working Group. Working Group Summary This draft has taken a while as it required extensive rewriting by a new editor following the previous time it was submitted to the IESG. This added quite a bit of time to the process, but has greatly improved the quality of the draft. There was a bit of controversy regarding a late IPR declaration. The result was the removal of an optional feature believed to be the sole material covered by the IPD disclosure. The IPR holder has been approached to ask whether they will consider updating the disclosure but no response has been received yet. Document Quality As this is a requirements and framework draft, there can be no implementations. Solutions work is building on these requirements. Stewart Bryant deserves special mention as the AD that resulted in the document largely being re-written, which improved its quality. Personnel Andy Malis is the Document Shepherd Adrian Farrel is the Responsible AD. RFC Editor Note Section 5 OLD: The solution SHOULD provide means to guarantee the traffic delivery to receivers (Integrity, Confidentially) NEW: The solution SHOULD provide means to protect the traffic delivered to receivers (Integrity, Confidentially, Endpoint Authentication)
Last Call: (RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability
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 MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics 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 2014-07-07. 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 An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/Multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR Block are related to Program specific information carried in MPEG TS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodability/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodability/ballot/ No IPR declarations have been submitted directly on this I-D.
TLS Working Group Interim Meeting, July 20, 2014
The TLS WG will hold an interim meeting prior to IETF90 from 10am-4pm on Sunday July 20. The most likely location will be the Mozilla offices in Toronto. The chairs will post details with an agenda and a final location closer to the meeting. Additional information will be announced on the TLS WG mailing list: http://www.ietf.org/mail-archive/web/tls/current/maillist.html
IETF 90 Preliminary Agenda
The IETF 90 Preliminary Agenda has been posted. The final agenda will be published on Friday, June 27th, 2014. Currently Registration and Breaks are not displaying. This will be remedied on the final agenda. https://datatracker.ietf.org/meeting/90/agenda.html https://datatracker.ietf.org/meeting/90/agenda.txt More information regarding IETF 90 in Toronto, ON, Canada is located here: https://www.ietf.org/meeting/90/index.html Thank you! IETF Secretariat
RFC 7282 on On Consensus and Humming in the IETF
A new Request for Comments is now available in online RFC libraries. RFC 7282 Title: On Consensus and Humming in the IETF Author: P. Resnick Status: Informational Stream: IETF Date: June 2014 Mailbox:presn...@qti.qualcomm.com Pages: 19 Characters: 52339 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-resnick-on-consensus-07.txt URL:http://www.rfc-editor.org/rfc/rfc7282.txt The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus. Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. 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/search 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
