WG Review: Binary Floor Control Protocol Bis (bfcpbis)
A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, October 18, 2011. Binary Floor Control Protocol Bis (bfcpbis) Status: Proposed Working Group Last Updated: 2011-09-20 Chairs: TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo gonzalo.camari...@ericsson.com Robert Sparks rjspa...@nostrum.com Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo gonzalo.camari...@ericsson.com Mailing Lists: General Discussion: TBD To Subscribe: TBD Archive:TBD The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Milestones: April 2012 Draft revision of RFC 4582 to IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Managed Incident Lightweight Exchange (mile)
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, October 18, 2011. Managed Incident Lightweight Exchange (mile) Status: Proposed Working Group Charter Last Updated: 2011-09-21 Chairs: TBD Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Sean Turner turn...@ieca.com Mailing Lists: General Discussion: m...@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive:http://www.ietf.org/mail-archive/web/mile Description: The Managed Incident Lightweight Exchange (MILE) working group will develop standards and extensions for the purpose of improving incident information sharing and handling capabilities based on the work developed in the IETF Extended INCident Handling (INCH) working group. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-network Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident information. The extensions and guidance created by the MILE working group assists with the daily operations of CSIRTs at an organization, service provider, law enforcement, and at the country level. The application of IODEF and RID to interdomain incident information cooperative exchange and sharing has recently expanded and the need for extensions has become more important. Efforts continue to deploy IODEF and RID, as well as to extend them to support specific use cases covering reporting and mitigation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents. RID enables the secure exchange of incident related information in an IODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work developed in the INCH working group which includes the data model detailed in the IODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure exchange of information. MILE will also leverage the experience gained in using IODEF and RID in operational contexts. Related work, drafted outside of INCH will also be reviewed and includes RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension efforts to improve the capabilities for exchanging incident information. MILE has several objectives with the first being a description a subset of IODEF focused on ease of deployment and applicability to current information security data sharing use cases. MILE also describes a generalization of RID for secure exchange of other security-relevant XML formats. MILE produces additional guidance needed for the successful exchange of incident information for new use cases according to policy, security, and privacy requirements. Finally, MILE produces a document template with guidance for defining IODEF extensions to be followed when producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and other policies, regulations, and laws restricting the handling of those reports * referencing structured security information from within incident reports * reporting forensic data generated during an incident investigation (computer or accounting) The WG will produce the following: * An informational document on IODEF Guidance. * A Standards Track document specifying the Real-time Inter-network Defense (RID). * A Standards Track document specifying the transport for RID. * An informational template for extensions to IODEF. * A Standards Track document for IODEF Extensions in IANA XML Registry. * A Standards Track document for IODEF Extension to support structured cybersecurity information. * A Standards Track document for Labeling for data protection, retention, policies, and regulations. * A Standards Track
CUSS Working Group Virtual Interim Meeting: October 25, 2011
The CUSS working group will hold a virtual interim meeting, with WebEx support, as follows: Date/Time: Tue, October 25 2011 @ 10:00 AM - 12:00 PM Chicago / 5:00 PM - 7:00 PM Frankfurt, Rome WebEx details for this meeting will be posted to the CUSS mailing list (http://www.ietf.org/mail-archive/web/cuss/). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-kitten-sasl-openid-06.txt (A SASL GSS-API Mechanism for OpenID) to Proposed Standard
The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A SASL GSS-API Mechanism for OpenID' draft-ietf-kitten-sasl-openid-06.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-10-25. 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 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-policy-uri-02.txt (Location Configuration Extensions for Policy Management) to Informational RFC
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Location Configuration Extensions for Policy Management' draft-ietf-geopriv-policy-uri-02.txt as an 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 2011-10-25. 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 Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-deref-protocol-03.txt (A Location Dereferencing Protocol Using HELD) to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'A Location Dereferencing Protocol Using HELD' draft-ietf-geopriv-deref-protocol-03.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-10-25. 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 to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HELD protocol to request the location of the Target. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2011-2012: Call for community feedback
As per RFC 5680, NomCom 2011-2012 is issuing a call to the entire IETF community for feedback on the Willing Nominees for the open IETF positions. Nominations for the open positions are now closed and the list of willing nominees is now quite stable. Why is feedback important? == Feedback is information you think will help NomCom make a decision on selecting candidates for open IETF positions. Feedback should be based on information you know first hand about an individual nominee. Community feedback is the most important input that determines who fills the open positions. We cannot properly execute the task of selecting the best candidates for the open positions without **YOUR** participation and feedback. Review the list of willing nominees and open positions == The open list is currently available on the Nomcom page and the entire community is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ where the list of willing nominees is available and sorted by open position. IMPORTANT NOTE: Access to the Provide Feedback pages requires an www.ietf.org login. Logins used for previous years' nomcom pages used the tools.ietf.org login, which is separate. To get a www.ietf.org login if you don't already have one, please go to this page: https://datatracker.ietf.org/accounts/create/ Means of providing feedback to the NomCom = You can use one (or more) of the following methods to provide feedback to the Nomcom: - The best method is to enter it directly on the NomCom website at https://www.ietf.org/group/nomcom/2011/input/ . Click on the name of the person who you are providing feedback about and enter the text you want to provide us. - Send an email to nomco...@ietf.org and be sure to identify the nominee and position the feedback pertains to. - Contact one (or more) of the Nomcom members by email. - Contact us in person in Taipei during our office hours. (to be announced soon) - You can provide **anonymous** feedback by contacting either the Nomcom chair or any of the Nomcom members who will anonymize it for the rest of the members. I would like to thank everyone who has provided us feedback already, and hope that more people from the community will take time to provide us further feedback. Suresh Krishnan Chair, NomCom 2011-2012 nomcom-ch...@ietf.org suresh.krish...@ericsson.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' to Proposed Standard (draft-ietf-sipcore-event-rate-control-09.txt)
The IESG has approved the following document: - 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' (draft-ietf-sipcore-event-rate-control-09.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ Technical Summary This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. Working Group Summary Many working group members tended to express mild confusion or bewilderment upon first encountering the behavior described in section 5 (minimum notification rate). It is worth noting that this is the exact behavior that is required by the GEOPRIV work. This confusion is typically ameliorated when they are presented with use cases similar to those being considered by GEOPRIV. Document Quality Martin Thompson provided significant input to the document on behalf of the GEOPRIV working group, who is an immediate customer for this document. Brian Rosen identified the suitability of this mechanism in satisfying GEOPRIV's requirements, and made the initial proposal for the minimum rate mechanism for that purpose. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 88 in Vancouver
The IAOC is pleased to announce Vancouver, BC, Canada as the site for IETF 88 from November 3 - 8, 2013. This will be the IETF's fifth meeting in Vancouver, the others being 18, 64, 70 and 84. IETF 88 was targeted to be held in Asia-Pacific, however after a 7 month search we were unable to find a venue on our dates, that was reasonably priced for attendees and sponsors, met our meeting space and technology requirements, and had an acceptable visa policy. We looked at a total of 43 venues in 11 cities including: Singapore Hong Kong Kuala Lumpur Shanghai Manila Seoul Vietnam Macau Auckland Bangkok, and Honolulu and Waikoloa In some venues guest room rates were over $300 a night, and for others the meeting space cost was among the very highest we have ever seen. Those disqualifying factors together with our commitment to completing venue selections three years in advance compelled us to make a decision and move on. The venue in Vancouver had been pre-qualified, has a guest room rate of $169 CAD including Internet, complimentary meeting space and a Welcome Reception sponsorship. And for the first time we negotiated an option for a future meeting with the same attractive features. While Vancouver clearly isn't in the Asia-Pacific region, it at least minimizes travel from many places in Asia. Our commitment to finding Asia-Pacific venues is unwavering, however as we have reported at Plenary we have experienced difficulties. We are moving ahead. We have a site visit scheduled in October for IETF 91 in 2014 and have a solid Host interest for 2015. Furthermore we are investigating the use of paid 3rd party intermediaries to negotiate arrangements in the region. We welcome your assistance and volunteering to Host or sponsor meetings in Asia-Pacific, and elsewhere. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 82 - Social Event
82nd IETF Meeting Taipei, Taiwan November 13-18, 2011 Host: Taiwan Network Information Center (TWNIC) Host Website: http://ietf82.tw/ Meeting venue: Taipei International Convention Center (TICC) http://www.ticc.com.tw/index_en.aspx Register online at: http://www.ietf.org/meetings/82/ 1. Registration 2. Social Event 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 11 November 2011 1700 PT (00:00 UTC) B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 07 November 2011 at 1700 PT ( UTC). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 11 November 2011, 1700 local Taipei time. G. On-site Registration starting Sunday, 13 November 2011 at 1100 local Taipei time. 2. Social Event: Cultural Night in Taipei Venue: Taipei World Trade Center Club at TWTC International Trade Building Taiwan Network Information Center is honored to welcome IETF delegates to the Cultural Night in Taipei held at the top of the TWTC International Trade Building, overlooking Taipei's latest developed business district. Taiwan is a place mixed with a variety of cultures. The Cultural Night in Taipei will present all the guests the most popular traditional ritual theatre performance, Techno Prince (Nezha), and the traditional Chinese orchestra. All the guests will also be given souvenirs made by folk artists. Date: Tuesday, November 15, 2011 Time: 7:00 PM - 10:00 PM Cost: US$ 40.00 Additional information can be found at: http://ietf82.tw/social_events.html To Register for social: https://www.ietf.org/registration/ietf82/eventticket.py NOTE: You must first register for IETF 82 to purchase a social ticket. Only 32 days until the Taipei IETF! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
